Передача сообщений между потоками Windows

Охуеть. Значится если человеку из потока А в поток Б надо передать сообщение - то ему надо для этого создать отдельный поток С и в нем "не торопясь" эти сообщения обрабатывать. Ню-ню...

Не, ну оно-то конечно можно для этих целей заюзать SQLBroker или MSMQ, почему-бы и нет. Ну или BizTalk че уж там.

Расскажи пожалуйста, как можно сбросить в очередь СОБЫТИЕ. Это будет новое слово в IPC.

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

да чо, я видел код который данными в другие процессы и потоки через registry швырялся, так что воспаленный ум еще и не то способен :). А как тебе создание кнопок и меню при первом вызове WM_PAINT главного окна :)?
 
окей, суть понял, читаю, просвещаюсь.
 
Поинтересуйся сигналами. Это, %лядь, действительно, событие для процесса.
Есть сигналы в никсах, есть ивенты в винде. Есть, не возражаю. А теперь расскажи мне как же их поставить В ОЧЕРЕДЬ по утверждению пациента (напомню что очередь суть дисциплина обслуживания ФИФО).
 
Есть сигналы в никсах, есть ивенты в винде. Есть, не возражаю. А теперь расскажи мне как же их поставить В ОЧЕРЕДЬ по утверждению пациента (напомню что очередь суть дисциплина обслуживания ФИФО).

Если человек идиот, то это надолго. Кто ж ему доктор, что он пхахет взаимоисключающие параграфы.
 
однако, господа, доктора-программеры...
Я где-то писал про три потока?

Интересно как некоторые приспособились: и через registry и даже BizTalk! У вас бохатейший ёпыт!
Взаимодействия между процессами смешались у вас с взаимодействием между потоками... и чем же интересно помешала дисциплина фифо?

Суть задачи напомню

как передать сообщение из одного потока в другой не блокируя выполнение первого?
Например, есть цикл, в котором идет обработка данных, по мере обработки возникают события, в обработчиках которых нужно сделать некоторые операции. Однако первый цикл выполняется с частотой 100мсек и нежелательно что бы обработка событий влияла на частоту исполнения первого потока, поэтому как по мне проще во втором потоке обрабатывать.

Человеку нужно инфу (т.е код события, т.е. события НЕ виндового) из одного потока (А) сливать в другой (В) с минимальными задержками. И правильно пишет человек, именно в другом потоке обрабатывать. И при чем тут юниксовые сигналы? Поток А записывает в очередь потока В и занимается далее своими делами, а В обрабатывает и т.п.

И где тут третий поток?

Как записать событие (т.е. НЕ виндовое событие) в очередь? Да! Страшнейшая проблема! Решение ее - новая веха.
 
однако, господа, доктора-программеры...
Я где-то писал про три потока?

Интересно как некоторые приспособились: и через registry и даже BizTalk! У вас бохатейший ёпыт!
Взаимодействия между процессами смешались у вас с взаимодействием между потоками... и чем же интересно помешала дисциплина фифо?

Суть задачи напомню

как передать сообщение из одного потока в другой не блокируя выполнение первого?
Например, есть цикл, в котором идет обработка данных, по мере обработки возникают события, в обработчиках которых нужно сделать некоторые операции. Однако первый цикл выполняется с частотой 100мсек и нежелательно что бы обработка событий влияла на частоту исполнения первого потока, поэтому как по мне проще во втором потоке обрабатывать.

Человеку нужно инфу (т.е код события, т.е. события НЕ виндового) из одного потока (А) сливать в другой (В) с минимальными задержками. И правильно пишет человек, именно в другом потоке обрабатывать. И при чем тут юниксовые сигналы? Поток А записывает в очередь потока В и занимается далее своими делами, а В обрабатывает и т.п.

И где тут третий поток?

Как записать событие (т.е. НЕ виндовое событие) в очередь? Да! Страшнейшая проблема! Решение ее - новая веха.

свои излагать понятно мысли научись, ага.
 
однако, господа, доктора-программеры...
Я где-то писал про три потока?
Да понимаешь, тут один дятел написал:
по сути. создай отдельный поток обработки сообщений и все события / сообщения сбрасывай в его очередь. а там уже не спеша их обрабатывай.
И вот мы тут думаем - что же этот дятел имел ввиду под словами "создай" и "отдельный"?

Человеку нужно инфу (т.е код события, т.е. события НЕ виндового) из одного потока (А) сливать в другой (В) с минимальными задержками. И правильно пишет человек, именно в другом потоке обрабатывать.
Ты дружище, просто дурак. Сначала погугли на разницу между СОБЫТИЕМ (виндовым, невиндовым, даже просто из реальной жизни) и СООБЩЕНИЕМ (тоже хоть виндовым, хоть из реальной жизни). Даже не так. Просто погугли что такое СОБЫТИЕ и что такое СООБЩЕНИЕ.
 
Ооо! Дятел написал, просто дурак! Ты дружище просто хамло гнойное. Фраза моя конечно корявая, не спорю, однако в философские споры по поводу разницы между сообщением и событием лучше не ввязывайся. Мозгофф не хватить
 
:попкорн:

Давай Эдвин, расскажи нам на что у нас еще мозгов не хватит. Ты давно академию Шаг закончил?
 
гуру разнервничались )))

я так понимаю человеку советом помочь надо, а не обрыгивать друг друга.
 
окей, суть понял, читаю, просвещаюсь.

Вариантов решения вашей задачи на самом деле много. Научитесь пользоваться MSDN.

Если не перечислять методы IPC, вам стоит использовать:
-Event
-Mutex
-Semaphore
-Waitable timer

Вот пример с использованием events:
Тільки зареєстровані користувачі бачать весь контент у цьому розділі


Я внес минимальные изменения в этот пример моделирующие вашу задачу:

Код:
#include <windows.h>
#include <stdio.h>

#define THREADCOUNT 4 

HANDLE ghWriteEvent; 
HANDLE ghThreads[THREADCOUNT];

HANDLE ghWriteThread;

DWORD WINAPI ThreadProc(LPVOID);
DWORD WINAPI ThreadWriteProc(LPVOID);

void CreateEventsAndThreads(void) 
{
	int i; 
	DWORD dwThreadID; 

	// Create a manual-reset event object. The write thread sets this
	// object to the nonsignaled state when it finishes writing to a 
	// shared buffer. 

	ghWriteEvent = CreateEvent( 
		NULL,               // default security attributes
		TRUE,               // manual-reset event
		FALSE,              // initial state is nonsignaled
		TEXT("WriteEvent")  // object name
		); 

	if (ghWriteEvent == NULL) 
	{ 
		printf("CreateEvent failed (%d)\n", GetLastError());
		return;
	}

	// Create multiple threads to read from the buffer.

	for(i = 0; i < THREADCOUNT; i++) 
	{
		// TODO: More complex scenarios may require use of a parameter
		//   to the thread procedure, such as an event per thread to  
		//   be used for synchronization.
		ghThreads[i] = CreateThread(
			NULL,              // default security
			0,                 // default stack size
			ThreadProc,        // name of the thread function
			NULL,              // no thread parameters
			0,                 // default startup flags
			&dwThreadID); 

		if (ghThreads[i] == NULL) 
		{
			printf("CreateThread failed (%d)\n", GetLastError());
			return;
		}
	}
}

void CreateWriteThread()
{
	DWORD dwThreadID;
	//   be used for synchronization.
	ghWriteThread = CreateThread(
		NULL,              // default security
		0,                 // default stack size
		ThreadWriteProc,        // name of the thread function
		NULL,              // no thread parameters
		0,                 // default startup flags
		&dwThreadID); 
}

void WriteToBuffer(VOID) 
{
	// TODO: Write to the shared buffer.

	printf("Main thread writing to the shared buffer...\n");

	// Set ghWriteEvent to signaled

	if (! PulseEvent(ghWriteEvent) ) 
	{
		printf("SetEvent failed (%d)\n", GetLastError());
		return;
	}
}

void CloseEvents()
{
	// Close all event handles (currently, only one global handle).

	CloseHandle(ghWriteEvent);
}

void main()
{
	DWORD dwWaitResult;

	// TODO: Create the shared buffer

	// Create events and THREADCOUNT threads to read from the buffer

	CreateEventsAndThreads();

	// At this point, the reader threads have started and are most
	// likely waiting for the global event to be signaled. However, 
	// it is safe to write to the buffer because the event is a 
	// manual-reset event.

	CreateWriteThread(); 

	printf("Main thread waiting for threads to exit...\n");

	// The handle for each thread is signaled when the thread is
	// terminated.
	dwWaitResult = WaitForMultipleObjects(
		THREADCOUNT,   // number of handles in array
		ghThreads,     // array of thread handles
		TRUE,          // wait until all are signaled
		INFINITE);

	switch (dwWaitResult) 
	{
		// All thread objects were signaled
	case WAIT_OBJECT_0: 
		printf("All threads ended, cleaning up for application exit...\n");
		break;

		// An error occurred
	default: 
		printf("WaitForMultipleObjects failed (%d)\n", GetLastError());
		return;
	} 

	// Close the events to clean up

	CloseEvents();
}


DWORD WINAPI ThreadWriteProc(LPVOID lpParam) 
{
	int i=0;
	while(i++<100)
	{
		Sleep(2000);
		WriteToBuffer();
	}
	return 1;
}

DWORD WINAPI ThreadProc(LPVOID lpParam) 
{

	while(1)
	{
		printf("Thread %d waiting for write event...\n", GetCurrentThreadId());

		DWORD dwWaitResult = WaitForSingleObject( 
			ghWriteEvent, // event handle
			INFINITE);    // indefinite wait


		switch (dwWaitResult) 
		{
			// Event object was signaled
		case WAIT_OBJECT_0: 
			//
			// TODO: Read from the shared buffer
			//
			printf("Thread %d reading from buffer\n", 
				GetCurrentThreadId());
			continue;
		default: 
			printf("Wait error (%d)\n", GetLastError()); 
			return 0; 
		}
	}

	printf("Thread %d exiting\n", GetCurrentThreadId());
	return 1;
}
 
Вариантов решения вашей задачи на самом деле много. Научитесь пользоваться MSDN.

Если не перечислять методы IPC, вам стоит использовать:
-Event
-Mutex
-Semaphore
-Waitable timer
А мессаджи где? Или в МСДН нет примера с мессаджами? ;)
 
А мессаджи где? Или в МСДН нет примера с мессаджами? ;)

Пример конечно же есть. Но я все таки отношу Messages в Windows к методам IPC. Следует разделять методы IPC и inter-thread communication. Также я привык приедрживаться принципа - чье предложение того и исполнение. Жду от вас реализации.
 
Но я все таки отношу Messages в Windows к методам IPC.
Ага. А функцию PostThreadMessage() придумали какие-то лохи из мелкомягких :)
Следует разделять методы IPC и inter-thread communication.
Это очень убогий подход: делить потоки и процессы в винде. Выбор средств IPC или межтредовой коммуникации должен определяться только потребностями и особенностями этой коммуникации - а не словами тред/процесс.
 
Ага. А функцию PostThreadMessage() придумали какие-то лохи из мелкомягких :)
Это очень убогий подход: делить потоки и процессы в винде. Выбор средств IPC или межтредовой коммуникации должен определяться только потребностями и особенностями этой коммуникации - а не словами тред/процесс.

Бред.

Ну так реализацию от вас мы увидим? Или вы не смогли скомпилировать пример? :D
 
Бред.

Ну так реализацию от вас мы увидим? Или вы не смогли скомпилировать пример? :D

А ты денег за работу заплатишь? Не все ж как ты будут копипастить из МСДН.
Вот сэмпл такой есть, специально для бюджетника-оршанского.
Тільки зареєстровані користувачі бачать весь контент у цьому розділі
 
А ты денег за работу заплатишь? Не все ж как ты будут копипастить из МСДН.

За какую работу? За пример из MSDN? Вы тут будете трындеть годами обсасывая выпады друг друга на сотни страниц, кичась какие вы тут все "специалисты", но ни один не приведет примера на 50 строчек.

Вот сэмпл такой есть, специально для бюджетника-оршанского.
Тільки зареєстровані користувачі бачать весь контент у цьому розділі

Хороший пример к вопросу об IPC и PostThreadMessage для BFG-9000. А в MSDN не нашли? Cколько же я вам должен за этот титанический труд? :D
 
За какую работу? За пример из MSDN? Вы тут будете трындеть годами обсасывая выпады друг друга на сотни страниц, кичась какие вы тут все "специалисты", но ни один не приведет примера на 50 строчек.
Хороший пример к вопросу об IPC и PostThreadMessage для BFG-9000. А в MSDN не нашли? Cколько же я вам должен за этот титанический труд? :D

Слушай, иди в жопу пожалуйста. Мы тут не нанимались лентяям сэмплы писать. Они так не научатся ничему и никогда.
 
Назад
Зверху Знизу