[Interest] Write from different thread

Giuseppe D'Angelo dangelog at gmail.com
Thu Aug 23 14:31:15 CEST 2012

On 23 August 2012 12:21, Marc Mutz <marc.mutz at kdab.com> wrote:
> Hi Giuseppe,
> I think you got the categories wrong.

Sorry, I rushed out the email and in the end it turned to be not
precise about what I was referring to with "safe".

> On Thursday August 23 2012, Giuseppe D'Angelo wrote:
>> Now we have:
>> 1) non-reentrant: safe to be used by only one thread
> non-reentrant means: no other thread may execute this function while you're
> calling it.

I was sticking to the Qt conventions
http://qt-project.org/doc/qt-4.8/threads-reentrancy.html (which aren't
universal, all the opposite).
Given your definition one could assume it's safe to call a GUI
function from any thread, provided that no other thread is calling it
at the same time. Instead it's not. Not sure if "non-reentrant" is a
good definition for such a case.

>> 2) reentrant: safe to be used by multiple threads, provided that
>> access is serialized ("one at a time")
> reentrant means: multiple threads may call this function at the same time,
> provided the input is different (for member functions, the instance (*this)
> is input, too!).
> If you can serialise access (_all_ access), you can even call non-rerentrant
> functions from multiple threads; the problem is that you usually don't
> control all access points, so you can't secure them all. As is the case with
> QObject event handling - you'd at a minimum have to reimplement event() to
> lock the mutex, but code can also call functions through your meta object,
> and you don't control the lifetime of the references you hand out to it, so
> you cannot lock the mutex since you don't know when to unlock again.

My point was that most QObject subclasses are marked to be reentrant.
While that's true, I wanted ask if it should be made more clear in the
docs that QObjects are always potentially accessed by the thread
they're living in (due to event dispatching, etc.), and therefore one
should refrain from accessing them from other threads. QObjects in
general are not tied to a specific thread (whilst instead GUI classes
are), but very tied to the thread they live in.

Giuseppe D'Angelo

More information about the Interest mailing list