Hi GSL members and (potential) friends of the Solar Mutex,
as one or the other already knows, I am actively (or should I write
desperately? :-) trying to somewhat clean up our threading-model and
-architecture. As the Solar Mutex being one of the foundations of our
current approach, I certainly need to fiddle somewhat around with it, so
I hope that you don't get mad at me, while I present my first questions,
ideas and plans ... ;-) Please find below my observations regarding
current implementations of the Solar Mutex respectively the Win32
thread-transparency (AFAIK, the other platforms are thread-transparent
anyway) as well as the issues I (think I) see and what I would like to
do to fix them.
Please give me feedback regarding the planned changes and if they are
reasonable from your point of view. These are just the first steps
before doing more changes to eventually make VCL Win32 "really"
thread-transparent and to finally get rid off the Solar Mutex. You may
want to take a look at the wiki page I created, to actually describe and
track my efforts and plans.
http://wiki.services.openoffice.org/wiki/Effort/Make_VCL_Thread-Transparent
Thanks for feedback and support
Kay
* SalYieldMutex (AKA Solar Mutex) Implementations
Observation: Poking around in VCL and the backends, I see different but
very similar implementations of the SalYieldMutex, which get returned as
the Solar Mutex by the Application::GetSolarMutex method. The
implementations for Mac and Unix seem to be even literally the same,
while that one for Win32 somewhat differs.
Issue: The SalYieldMutex implementations all are derived from
vos::OMutex, adding two members
- ULONG mnCount
- vos::ThreadIdentifier mnThreadId
The mnCount member is kept in sync. with the number of acquires and
releases. This is needed for recursive Application::Yield/Execute etc.
calls, to be able to "drop pants" while blockingly waiting for messages.
Regarding the mnThreadId, the situation seems to be more complicated. If
I understand correctly, this is really only used on Win32, to actually
"ensure" some kind of rescheduling in combination with the now obsolete
RVP JavaClient. The Solar Mutex being a member of the SalInstance
actually prevents it to be acquired before initializing VCL respectively
to be released (accessed) after de-initializing it, which already lead
to problems with respect to start-up or shutdown. Having multiple
implementations of the same functionality decreases maintainability.
Plan: If I understand correctly, there are no reasons left to keep the
SalYieldMutex implementations independent, neither have it hold any
thread IDs. Therefor I plan, certainly if no one objects, to consolidate
the different implementations into one implementation, to be provided
statically by the independent part of VCL, ensuring that it may be
acquired before initialization respectively be released after
de-initialization.
* VCL Thread-Transparency on Win32
Observation: Reading through the VCL Win32 backend implementations, I
can see a number of self defined window messages (SAL_MSG_...) to be
send to an invisible instance of a dynamically registered Window class
(SAL_COM_CLASSNAME). Most of these messages become send to the instance
of this class by using the synchronous "SendMessage" function (while
some are send with "PostMessage"). If I understand correctly, the idea
behind this is, to enforce a thread switch to the thread owning the
invisible window, if necessary, and to eventually dispatch this message
e.g. to create a window.
Issue: With my naive mind and with my only rudimentary knowledge of VCL,
this seems to be unnecessary complex as the underlying goal (which
actually seems to be thread-transparency :-) is not reachable with the
current approach. Taking a look e.g at how windows become created, my
understanding is, that the Solar Mutex needs to be acquired beforehand,
leading to the situation, that invoking "SendMessage" to do a thread
switch to the main-thread can never happen, in case the thread currently
trying to actually do the switch is not the main-thread, basically
rendering the "SendMessage" approach at best questionable (please
correct me if I am wrong).
Plan: As VCL must only be called by the main-thread in most/many cases
anyway (at least on Win32) and it therefor is thread-affine, I suggest
to just remove all unnecessary "SendMessage"s, including the
indirections and the invisible window instance, replacing them with
direct calls. This would not change overall behavior in any noticeable
(hopefully :-) way and would ease maintenance of the Win32 backend
significantly.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
