Цель такая : хочу сихронизировать запись в 1 файл лога сообщений из нескольких потоков. 
Для этого посылаю из этих потоков указатель на сообщения с помощью PostMessage. 
Сообщения посылаются главной и единственной форме приложения, в классе которой сидит прцедура их обрабатывающая.
Потоки создаются TidTCPServer.
Идея такая, что даже если два или несколько сообщений одного типа отправятся одновременно то они корректно встанут в очередь и 
последовательно обработаются моей процедурой обработки.

Вопрос : Я прав? Или тут есть какие-то нюансы, которых я не знаю или проблемы, которых не вижу?

в теории все красиво)
напишешь работающий алгоритм - увидишь недочеты.
на вскидку вопрос:
кто будет память из-под сообщений вычищать?

Ну PostMessage имеет очередь, должно обрабатывать корректно.

а доступ к данным под указателем как разруливать будешь?

Я планировал примерно так



Нужно делать что-то еще?

Это сообщение отредактировал(а) Girder - 22.1.2007, 15:27

это обращение к переменой 

и если оно из потока, то оно не защещено, хотя при чтении это не смертельно , хотя и не хорошо

Я так понимаю что New(pS) каждый раз выделяет память под новую строку, адрес которой никто кроме обрабатывающей процедуры не узнает, а стало быть никогда ее не прочитает и не узнает. Поэтому, т.к. обрабатывающая процедура процедура выполняется в основном потоке данный код будет равносилен добавлению в СтрингЛист обычной глобальной переменной. Как будто бы и небыло никаких потоков. Я не прав ?


Это сообщение отредактировал(а) Steel - 22.1.2007, 09:12

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

в пределах одного приложения таки можно не извращаться, так как менеждер один и тот же.
Steel, делай как задумал.

несколько замечаний по исходному коду
1) кто так память под string выделяет?! может я и не прав, но имхо объявление ^String.... это изврат) выход: использовать PChar;
2) pS - глобальная переменная, потоконебезопасна.
что будет если при выполнении процедуры SendMsg в одном потоке управление после New(pS) перейдет к другому потоку??
выход: использовать локальную переменную-указатель.
3) PostMessage не гарантирует обработку сообщения. в случае ошибки в главном(обрабатывающем) потоке получишь утечку памяти. выход: использовать другой способ синхронизации между потоками. например посмотри ДНК TThread.Synchronize.

это из другой оперы. одно дело - нотификация, другое - синхронизация.


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

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

одно дело просто нотификация, другое дело, когд один кусок кода память выделяет, другой освобождает. это ну совсем не есть хорошо. опять же имхо.
а Synchronize я привел для примера реализации обработки некоторых данных(выполнении некторого кода) из разных потоков в контексте одного(главного) потока. конечно это все просиходит синхронно. зато потокобезопасно.


излишняя безалаберность в программировании приводит к появлению таких глюков (трудноуловимые AV например), которые замучаешься потом отлавливать. 
так зачем усложнять себе будущую жизнь, не лучше ли изначально все нормально сделать? конечно 100% безглючный код практически нереально сходу создать, но стремиться то к этому надо!

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


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

Как вы наверное заметили я не слишком силен в потоках.
Поэтому. Если не трудно. Было бы неплохо получить пример обработчика OnExecute компонента TIdTCPServer, который что-либо выполняет в основном потоке.

PS использую Indy9

Спасибо всем кто мне помогал. То что хотел - реализовал. Насколько успешно - покажет время.