Всем доброго времени суток. Читаю книгу Джефри Рихтера по WIN32, изучаю Visual C++. 
Дошел до Оконных Сообщений. Мне практически понятен принцип... но есть пара глупых вопросов...
В чем отличие Синхронных от Асинхронных сообщений?     

синхронные сообщения передаются в оконную процедуру напрямую, т.е. в том же потоке, где и вызывается SendMessage, а результат обработки сообщения возвращается непосредственно из SendMessage

асинхронные ставятся в конец очереди сообщений с помощью функций PostMessage, SendNotifyMessage и SendMessageCallback
результат их обработки ни как не передается обратно, поскольку реальная обработка такого сообщения, в общем случае, не связана с текущим потоком, в котором это сообщение было отправлено, поэтому и передача любых локальных указателей (на стековые переменные) с асинхронным сообщением повлечет за собой ошибки доступа по несуществующим адресам памяти

синхронные используются когда необходимо немедленно получить результат

асинхронные удобно использовать, когда нужно уведомлять окно о каких-либо произошедших событиях, не дожидаясь на них реакции окна, например: из параллельных потоков

Немного уточню. Все в разъяснении GremlinProg будет правильно, если под "потоком" подразумевается поток управления, а не поток в в смысле "thread". Сообщение, синхронное или асинхронное - всегда обрабатывается в том потоке (thread), которому принадлежит окно. Если сообщение послано синхронно окну другого потока, то посылающий поток приостанавливается до обработки сообщения. Таким образом возникает иллюзия обычного вызова функции.
Но это нужно понимать очень хорошо, т.к. здесь возможно возникновение dead-lock'ов. Поэтому разумно посылать сообщения синхронно, только если это действительно нужно. А при посылке сообщения окну другого потока анализировать возможность взаимоблокировок.

Earnest, ну ты так его совсем запутаешь, теперь он будет сомневаться, что такое поток
поток он и в африке бы был потоком, если бы не STL со своим нововведением stream, все остальное как ни назови, нить, поток - условно разделенные во времени "процессы", исполнение которых может накладываться друг на друга в одних и тех же временных интервалах
окно - не поток, и нету у него специального потока управления, оно может только принадлежать потоку, т.е. управление его поведением производится только во время работы этого потока-владельца

если создать в двух разных потоках два окна, то они уже не будут работать на одной временной шкале, т.е. в любом случае, синхронная передача сообщений между ними потребует синхронизации между этими потоками, что и делает SendMessage
PostMessage - синхронизирует только доступ к очереди сообщений, чтобы вставить новое сообщение, поэтому, она более лояльна к асинхронным операциям

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

GremlinProg, ты не прав. Потоки ввода\вывода здесь вообще непричем. Поток управления и поток - thread - совершенно разные вещи. Когда мы говорим о потоке управления, то имеется в виду последовательное выполнение операций, где мы четко знаем: сначало делаем это, потом это,... В Windows-приложении поток управления очевиден только в рамках обработки одного сообщения. Т.е. непосредственно обработчик и все, что из него синхронно вызывается. В этом смысле обработка синхронных сообщений происходит в том же потоке управления. А вот обработка асинхронных сообщений может происходить в том же потоке-thread, но в совершенно непредсказуемый (не связанный с точкой вызова) момент. В этом смысле она происходит в другом потоке управления.

А я что говорю. Вся оконная функция выполняется исключительно в том потоке, которому принадлежит окно.

Не... процедура и функция это уже точно не терминология для C-программиста. Void -это тоже результат, что, кстати бурно используют всякие бусты. Главное, что там есть return - явный или неявный.
А разница такая. Синхронная посылка - это посылка с уведомлением о вручении, которого мы ждем. Неважно, чье окно, поток управления не сдвинется с места (SendMessage не вернет управление), пока сообщение не будет обработано. Как это достигается - неважно. А асинхронная посылка - это послали и забыли. 


Вот и пусть сомневается заранее, умнее будет. Кстати, GIK, Рихтера нужно читать не один раз. Лучше сначала галопом наискосок, ознакомиться. Потом вдумчиво, избранные места (по желанию). Насколько я помню, там прекрасно разъяснена разница между синхронными и асинхронными сообщениями. Просто не нужно останавливаться на каждом непонятном слове. Читай дальше, поймешь.

ну, про потоки ввода вывода я и не пишу
речь идет как раз об общем случае, в котором нет уточнений о том, какие существуют особенности асинхронных пересылок: в одном потоке, или в разных; один поток - это частный случай, который и выделяется соответственно в документации, например так:

поэтому и не разделяю такое мнение:

хорошо, что расшифровала "потоки управления", хотя потоком, в контексте асинхронных пересылок, я бы это не называл, поскольку очевидна путаница в терминах, это цепочка, или итерация, как удобно, но не поток, мы же не называем тело цикла потоком, а здесь, думаю, эта асоциация более верная

думаю только зря я обобщил Post и Send, поскольку разница между ними как раз в очередности обработки:
Post - ставит сообщение в конец очереди
Send - в начало (хотя "в начало" - это лишь условность, поскольку это равнозначно передаче сообщения непосредственно в процедуру окна, обычно так и пишут "calls the window procedure")

Добавлено через 8 минут и 6 секунд

поэтому в си и нет процедур )

Ну это не то чтобы путаница в терминах, а скорее историческое использование слова "поток" для перевода различных сущностей: stream - поток ввода\вывода, workflow - поток управления, thread - поток выполнения. Я понимаю, что по-русски мутновато получается, зато по английски все предельно ясно. Недаром одно время были активные сторонники переводить thread как "нить", чтобы не путать с workflow. Но как-то не прижилось. 

Раз уж пошла битва цитат, то вот что говорит MSDN о SendMessage:

Так что SendMessage ни в какую очередь ничего не помещает, а вызывает оконную процедура напрямую или делает вид, что вызывает напрямую.

  
Народ, Бальшой Прибальшой Спасиб что разьяснили... щас буду обмозговывать   

чет я ваще запутался товарищи   наверно я ваще тупой как дуб   Читаю уже несколько раз, пытаюсь скомпоновать Вашу инфу с Рихтером, и в голове такой бардак....
Давайте со мной как с ребенком, я щас буду свою мысль выкладывать а Вы плиз, по возможности поправте меня...
1) Как я понял Синхронное сообщение отличается  от Асинхронных тем, что Синхронное обрабатывается сразу или почти сразу, т.е. в первую очередь. Я прав, только в этом отличие?   или еще - поток (пусть пока поток создавщий окно-поток управления) ждет когда оно обработаеться, т.е. асинхронное не ждет? 
2) [quote(Рихтер)]
Вот как работает SendMessage. Если поток вызывает SendMessage для посылки сообщения окну, созданному им же, то функция просто обращается к оконной процедуре соответствующего окна как к подпрограмме. 
[/quote]
[quote(GremlinProg )]
синхронные сообщения передаются в оконную процедуру напрямую, т.е. в том же потоке, где и вызывается SendMessage, а результат обработки сообщения возвращается непосредственно из SendMessage
[/quote]
Т.е. неставиться в очередь структуры THREADINFO, а обрабатывается сразу в оконную процедуру, или между оконной процедурой и посылом сообщения есть еще что то по мимо структуры THREADINFO в которой и содержатся все сообщения? 
И еще, вот это:
    
и есть оконная процедура?    или это что то недокументированное?

Объясните пока только это, а про посыл другим окном (не из вызывающего процесса) пока ненадо, а то у меня в голове такая каша теперь  

не спорю, читай внимательно, что я по этому поводу написал, условность я ввел только для обобщения работы для методов post и send, чтобы разница была наглядной, чтобы общее между ними была очередь сообщений
GIK, я попробую привести упрощенный аналог

главный цикл обработки сообщений:

так можно показать главный цикл сообщений (Main message loop), т.е. на каждой итерации извлекается последнее сообщение из очереди и передается на обработку в процедуру окна

теперь, допустим где-нибудь мы вызываем метод SendMessage(так-же, упрощенно):

а теперь то же самое, только асинхронно:

ну вот и разница
оконная процедура - это WindowProc,
Main message loop - это главный цикл обработки сообщений, в нем как раз и осуществляется работа с очередью и обработкой сообщений

тут я явно показал зависимости для наглядности, можно, конечно точнее, но тогда получится многобуков, будет непонятно

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

Отетьте теперь на такой вопрос:
Передавая синхронное сообщение другому потоку, это сообщение, (если поток не занят)ожидается функцией GetMessage, и уже после нее СТАВИТЬСЯ В ОЧЕРЕДЬ синхронных сообщений, а НЕ отсылается сразу на обработку в WindowProc(), как это делается при отправки сообщений в ЭТОМ же потоке. 
Это так или нет? 

И еще, все таки, через:


проходят какие сообщения? 

Нет, то что посылается через SendMessage, никогда в очередь не попадает. И в цикл GetMessage, соответственно, тоже. Просто вызывающий поток приостанавливается, а внутри SendMessage происходит переключение на поток окна и передача ему управления.