синхронизация доступа к расшаренным данным в хуке

[Алексей++]

имеется DLL с подобным кодом

Код:

SECTIONS
	.SHARDATA   Read Write Shared
EXPORTS
	myhook
	get_m

Код:

#pragma data_seg(".SHARDATA")
static int m=0;
#pragma data_seg()

LRESULT CALLBACK myhook(int nCode, WPARAM wParam, LPARAM lParam)
{
	m++;
	return CallNextHookEx(0,nCode,wParam,lParam);
}

int get_m()
{
	return m;
}

следует ли учитывать многопоточность? Может ли код хука одновременно быть вызван из разных процессов, куда dll подгружена ?

(мне интуиция подсказывает, что следует, особенно при наличии метода, подобного get_m() )

--------------------------------------

и ещё вопрос - я так понимаю, про размещение в shared переменных типа map можно и не думать, так как там будет практически бесконтрольная работа с кучей

а если я размещу туда вектор с инициализированной длиной (и не буду её менять) - это нормально ?

Код:

static std::vector<int>(10,0);

[Алексей++]

wParam [in]
Type: WPARAM
Specifies whether the message was sent by the current thread. If the message was sent by the current thread, it is nonzero; otherwise, it is zero.

что значит - "текущим потоком" ?  Или имеется в виду " поток, установивший хук" ?

[Dimka]

Алексей++, начни с SetWindowsHookEx

dwThreadId
[in] Specifies the identifier of the thread with which the hook procedure is to be associated. If this parameter is zero, the hook procedure is associated with all existing threads running in the same desktop as the calling thread.

Не знаю точно, что такое "associated with thread", но раз hook обрабатывает системные сообщения, то, надо полагать, он будет дёргаться всякий раз, как в системе кто-то кому-то пошлёт соответствующее сообщение. Т.е. сработает в контексте любого потока, который это сделает.

Поэтому, если тебе надо, заведи именованный мьютекс - один на все процессы - и не парься.

[Алексей++]

Dimka, там имеется в виду, что хучится будет именно указанный поток , для глобального хука указывается 0. И это мой случай

ладно, мутекс, так мутекс. А где его лучше расположить - в расшаренных или "личных"  ?  Разница вроде в одном и множестве экземпляров, но мутекст то, он всё равно именованный будет, работать будет в обоих случаях

[resource]

Насчёт самого первого вопроса.
Ты можешь проверить, если напишешь что-то наподобие

Код:

LRESULT CALLBACK myhook(int nCode, WPARAM wParam, LPARAM lParam)
{
    volatile int a = m;
    Sleep(0);
    TRACE("a = %d for Thread %u", a, GetCurrentThreadId());
    m++;
    return CallNextHookEx(0,nCode,wParam,lParam);
}

Реализация трэйсов любая, лишь бы трэйсы шли 

[Алексей++]

resource, а каким образом это прояснит ? )  Кстати, трейс в дебаг не идёт, даже еслиотладку запускать средствами студии ))

ну это ладно, разобрались уже вроде

[resource]

Прояснит очень просто. Если обработчик не будет выполняться одновременно в двух разных потоках, то каждое конкретное значение переменной "a", может быть только в одном трэйсе, т.е. не может быть двух и более трэйсов с одним и тем же значением "a". Достаточно поставить хук на какое-нибудь частое событие, например WH_CALLWNDPROC.

Я так полагаю, что "дебаг" это окно в Visual Studio. Хз чего в него там идёт, и как работает твоя реализация трэйсов. Скажу страшную вещь, я энтерпрайзно не использую студию. А вот DbgView и WinDbg отлично показывают, то что я вывожу через тот же OutputDebugString. Но яж не зря сказал, что реализация любая. Т.е. можешь, например, писать в файл, в пайп, в сокет,  да хоть по RPC, лишь бы для твоего случая подходило.

[Алексей++]

resource, наверное, более логично выводить номер потока  )) Попробую в файл

[Алексей++]

хм, а правильно ли я понимаю, что расшаренном блоке вообще не должно использоваться выделение на куче (через new или в составе STL) ?  Ведь выделенная память уже не будет принадлежать шаре

то есть, массив у нас по старинке
int m[100];

[resource]

более логично выводить номер потока

Лёш, вот во-первых чем тебе ThreadId не номер потока? А во-вторых это вообще значения не имеет (для красоты). Можно вообще выводить

Код:

 TRACE("%d", a);

Этого достаточно.

Насчет динамически выделяемой памяти (хоть из кучи, хоть не из кучи) отвечу по-сишному. Я могу хранить в шаредной секции указатель на любой буфер и динамически выделять под него память. Главное синхронизировать к нему доступ, если он осуществляется одновременно из разных потоков (это мы и хотим выяснить, как я понимаю). Думаю, что и "наплюсить" можно подобным образом.

[Алексей++]

resource, с выделением у меня что-то не так делается, либо я вообще в корне что-то неверно делаю Придётся тебя в понедельник помучать вопросами, если ты не против

[resource]

Я никогда не против ) Но имей ввиду, я не плюсач. Про многопоточность и синхронизацию я кое-что знаю (сам себя не похвалишь...), но если речь пойдёт про плюсовые контейнеры, то надеюсь к дискуссии подключится кто-то ещё.

[Алексей++]

resource, да фиг с ними, с контейнерами, тут они, похоже, не помощники. Можешь мне в ЛС скайп закинуть ?

[Dimka]

Алексей++, разумеется, выделение в куче не годится. Выделяешь кусок памяти - общий. Получаешь на него указатель. Приводишь тип указателя к какой-то структуре с полями и массивами внутри. И эта структура будет картой статического распределения памяти в этом куске по разным переменным. Ну и пользуйся себе. Статические массивы в структуре либо резервируй с запасом по размеру, либо делай хитрый протокол взаимодействия процессов, что один процесс массив забил полностью, сигналит другому, чтобы тот вычитывал и освобождал - в общем, канал получится. Но если передача однанаправленная, может смысл есть как раз канал (pipe) и использовать. Важно, чтобы структура была платформонезависимой - т.е. если с ней работают как 32 так и 64 битные приложения, чтобы у них ни по размерам типов, ни по выравниванию полей не было различий.

[Алексей++]

Dimka, да, я примерно так себе уже и представлял - либо буфер ограниченного размера с постоянной вычиткой хозяином хука, либо связь через пайп или сокет