Hello,
does somebody know of a (solution) of a case when it would be useful to make
another thread temporarily act if it held the SolarMutex? I've recently ran
into 2 such cases:
- Calc threading - the Interpret() call may spawn several threads to compute
in parallel a whole formula group. SolarMutex is still held by the main
thread and the child threads generally try to avoid locking (it's ensured
beforehand they will operate on distinct data). However, some functionality
requires SolarMutex and those operations are currently blacklisted for
threading, since this would deadlock. The main thread cannot release
SolarMutex just like that in the middle of a computation, another independent
thread could possibly access a state that's inconsistent at the moment.
However, the main thread is blocked waiting for its child threads and so
semantically all those threads "own" the SolarMutex, the child threads are
there simply to use all CPU cores. I even remember seeing a piece of code
which simply "silently" (with just a log warning) bails out if it can't
acquire the SolarMutex.
- Clipboard handling on Windows - I'm a bit hazy on the technical details, but
if I'm getting it right, OLE requires all clipboard handling to be done by
one thread, which our clipboard code does by creating a dedicated clipboard
thread. Most clipboard operations ask the clipboard thread to do the job and
block waiting for it, but setting clipboard content is currently
asynchronous, because decoding the set content requires SolarMutex, and again
trying to acquire it from the clipboard thread would deadlock if the main
thread holding it would block waiting for the clipboard thread. But the
current situation with delayed handling can lead to previous clipboard
contents freed too late, causing a crash. And again, this is really just one
thread asking another one to do an operation, so again the clipboard thread
could be semantically considered an owner of SolarMutex during such an
operation.
So, has somebody already handled a case like this? And is there a better way
of handling this than adding some explicit ownership-yield operation to
SolarMutex? It sounds a bit dirty to do something like that, but I can't
think of anything better.
--
Luboš Luňák
l.lunak@collabora.com
Context
- Temporarily yielding SolarMutex to another thread · Luboš Luňák
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.