Kay Ramme - Sun Germany - Hamburg wrote:
> Hi Philipp,
>
> Philipp Lohmann - Sun Germany wrote:
>>
>> How sure are you that thread switching can only happen in a "message
>> related function" ? Then what exactly constitutes a "message related"
> Quite sure, just take a look at
>
> http://msdn2.microsoft.com/en-us/library/ms644950.aspx
>
> somewhere in the middle you find:
>
> "Messages sent between threads are processed only when the receiving
> thread executes message retrieval code."
>
> This actually is the documentation for "SendMessage" ...
>
>> function ? Most likely the main thread would be either waiting for the
>> solar mutex (basically in osl_acquireMutex, that is probably in
>> EnterCriticalSection) or it would wait for events and has released the
>> solar mutex anyway (this is the most likely case, the main thread is
>> yielding and therefore has released the solar mutex) and waits in
>> GetMessage anyway, which certainly qualifies as "message realated" ;-) .
>
> The first example basically matches what I tried to outline in my other
> mail. E.g.
>
> - The main-thread (the one owning the invisible window) is not in VCL.
> - Another thread wants to create e.g. a window. It therefor locks the
> Solar Mutex, calls into VCL and eventually blocks in "SendMessage",
> waiting for the main-thread to receive the non-queued message.
> - The main-thread comes back and tries to lock the Solar Mutex as well,
> before actually entering VCL.
>
The main thread (the one that does Application::Execute() cannot be "not
in vcl". The only time it looses the solar mutex is during Yield() or if
someone releases the mutex explicitly. Moreover the SAL_MSG processing
does explicitly not lock the solar mutex; it gets only locked after
dispatching the message (see WinSalInstance::Yield).
> The second example is not much better. E.g.
> - The main-thread is in VCL, had locked the Solar Mutex before calling
> in, eventually releases the Solar Mutex directly before calling
> "GetMessage", where it blocks.
> - Another thread wants to create a window. It therefor locks the now
> unlocked Solar Mutex, calls into VCL and eventually blocks in
> "SendMessage", keeping the Solar Mutex and waiting for the main-thread
> to receive the non-queued message.
> - The main-thread falls out of GetMessage and tries to reacquire the
> Solar Mutex.
No, see above. The SAL_MSG_* dispatcher will not lock the solar mutex.
It doesn't need to because it KNOWS that someone has it and is waiting
synchronously for the message to be processed.
At least that is how it works now as far as I understand it.
Just my 2 cents, pl
--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
-- Author unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
