Temporarily yielding SolarMutex to another thread
l.lunak at collabora.com
Fri Feb 1 17:05:13 UTC 2019
On Friday 01 of February 2019, Noel Grandin wrote:
> On Fri, 1 Feb 2019 at 17:11, Luboš Luňák <l.lunak at collabora.com> wrote:
> > - Calc threading - the Interpret() call may spawn several threads to
> > compute
> This case smells like this functionality should be using a different mutex
> instead of the SolarMutex, then the main thread could hold some kind of
> InterpretMutex, and the child threads could acquire and release the
> SolarMutex as necessary.
That wouldn't work. As I said, the main thread cannot release SolarMutex at
that point, since any other thread could acquire it there. And as long as the
main thread cannot release SolarMutex, no other thread can acquire it, not
even the child ones. And as long as the child threads cannot own SolarMutex,
they cannot use all kinds of LO functionality that require it, not just Calc
code, but anywhere.
> Perhaps the calling thread should pass both an operation and a
> std::function to the clipboard thread, which the clipboard thread can post
> back to the event thread once it's done - kind of a poor mans continuation.
We have places locking SolarMutex all over the codebase. That'd be such a
mess to do it from places that the child thread could possibly reach. Playing
tricks with mutexes would be a nice clean approach compared to that.
> "freed too late" ? sounds like an ownership issue, not a threading issue?
It's roughly like this: There's SdrModel and some SdrObject instances, which
refer to the SdrModel. Some SdrObject may get added to clipboard contents.
Later, when it all is about to get deleted, first all SdrObject instances get
deleted from whatever may refer to it, which includes resetting clipboard
contents to something that no longer refers to it. And when all that is done,
SdrModel is destroyed too.
Except, Windows clipboard handling decided it would be fun to delay resetting
clipboard contents, and so one SdrObject actually gets destroyed only later,
when the clipboard code finally gets to it. SdrObject dtor refers to the no
longer existing SdrModel, *boom*.
The way I see it, this is clearly a fault of the Windows clipboard code.
> I'm sure it is possible to get clever with mutexes, but I suspect you'd
> just be setting yourself up for bugs that are even harder to reason about.
I disagree. Getting clever with mutexes indeed looks very wrong
theoretically, but in practice it'd be a hack that'd be limited to a small
scope. Assuming it doesn't deadlock (which should be easy to spot) and
assuming it doesn't have a performance impact, what else can go wrong in
l.lunak at collabora.com
More information about the LibreOffice