Discussion about "Threads, Events and QObjects" article

[Wolf P.]

Gerolf, I see. The somewhat outdated framework I worked with, provided only the forking.
Do you know a good real-world example?

Peppe, as I see, to join means simply to wait?

[giesbert]

Join means wait for finish, yes.
I have some in my work, but they are not open source :-)
removing objects, which are are internally multithreadded for example. You have to close all threads before removing the object.

[dangelog]

[quote author="Wolf P." date="1292847084"]Gerolf, I see. The somewhat outdated framework I worked with, provided only the forking.
Do you know a good real-world example?

Peppe, as I see, to join means simply to wait?[/quote]

I was pretty sure it was standard lexicon when it comes to threading: it means "block the calling thread until the target thread terminates"; and yes, it's what QThread::wait() does. See for instance:
http://www.kernel.org/doc/man-pages/online/pages/man3/pthread_join.3.html
http://download.oracle.com/javase/6/docs/api/java/lang/Thread.html#join()
http://perldoc.perl.org/threads.html#DESCRIPTION

Now that you're telling me, perhaps should I change that term?

[goetz]

I must admit, I did not read the wiki article, but have some experience with QThread. The term "join a thread" was unknown to me, so although this might be a common term in threading in general, it seems it is not used in Qt world.

[giesbert]

It is common in Boost threadding for example, that's where I know it from. If it is a general term... ???

[dangelog]

I can put a footnote and/or a link there, just in case. The point is that you should know what QThread::wait() is for. What do you think?

[goetz]

Knowledge about QThread::wait() is definitely needed.

maybe this wording is a bit more clear:

"how to start, stop, wait for a thread (aka join a thread in boost and others) under (at least) one major operating system"

[Wolf P.]

[quote author="Volker" date="1292850647"] "how to start, stop, wait for a thread [/quote]
This sounds very familiar to me (FYI: Win32/VCL).

[dangelog]

Ok, I changed the sentence to
[quote]
how to start and stop a thread, and wait for it to finish, under (at least) one major operating system;
[/quote]

Thank you all for your feedback :)

[Wolf P.]

Another choice of terminology has me confused: reentrant. Thread-safe I understood, but the definition of reentrancy seemed not clearly demarcated from it. Maybe a slight reworking of the text could help for a better understanding of the difference.

[Wolf P.]

Sorry for this naive comment. Finally I found that this is Qt terminology: http://doc.qt.nokia.com/latest/threads-reentrancy.html

[Franzk]

It is not just Qt terminology. It's general programming terminology and something everyone who does at least the slightest bit of multi-threading should know about.

http://en.wikipedia.org/wiki/Reentrant_(subroutine)
http://en.wikipedia.org/wiki/Thread_safety

[Wolf P.]

[quote author="Franzk" date="1292858262"]...and something everyone who does at least the slightest bit of multi-threading should know about.[/quote] thx for the WP references :)

BTW: I did some multithreaded coding without problems, and without thinking about reentrance.

[dangelog]

To be honest, the little problem is that there might be some confusion due to literature and/or other toolkits. That's why I specified that in the article I follow the Qt conventions; anyway, I added a link to http://doc.qt.nokia.com/latest/threads-reentrancy.html, just to make it even more clear :-)

[Franzk]

It's good. The basics are the same across libraries though (bad library if it diverges...).

[Wolf P.]

After reading "Reentrancy and Thread-Safety":http://doc.qt.nokia.com/latest/threads-reentrancy.html , I think the term reentrance is not the best choice, because re-entering (in a sense of entering it twice) isn't really possible. (My problem seems to be that I'm familiar with the non-reentrance of MS-DOS.)

Classes that can be safely used by different threads at different times, I would name just safe. To be honest, I would not discuss it at all, but rather mark those that cannot be used from different threads at different times, maybe as "tread-local" or so.

Am I completely wrong here?

[giesbert]

Hi Wolf,
Thread-local is normally used for members/memory. So there is the "ThreadLocalStorage":http://en.wikipedia.org/wiki/Thread-local_storage for example. "Reentrant":http://en.wikipedia.org/wiki/Reentrant_(subroutine) and "thread-safety":http://en.wikipedia.org/wiki/Thread_safety are general terms (from my understanding) which are widely used. So I would stay with the used terms.

[dangelog]

[quote author="Wolf P." date="1292922748"]
Classes that can be safely used by different threads at different times, I would name just safe. To be honest, I would not discuss it at all, but rather mark those that cannot be used from different threads at different times, maybe as "tread-local" or so.

Am I completely wrong here?[/quote]

There are three possible cases:

• Classes/methods/objects/functions/data structures which (...whose instances) can be used at the same time from multiple threads, without the need of serializing cuncurrent accesses. That's what thread-safe means.
• Classes/methods/objects/functions/data structures which (...whose instances) cannot be used at the same time from multiple threads, therefore all accesses must be externally serialized. That's what reentrant means. Notice that
  ** Thread-safe implies reentrant
  ** Taking a reentrant class and forcibly serializing all possible accesses with a mutex makes it thread-safe
• Classes/methods/objects/functions/data structures which (...whose instances) cannot be used from multiple threads at all. There isn't a specific name for this case (we usually say "not thread-safe nor reentrant"). For instance, QWidget and all of its subclasses are usable only from the main thread.

[Wolf P.]

Ok. The term reentrant (in the given context) is now clear to me.

But please note the following example: when you call the Win32 function SendMessage (sending to another process) and get reply-blocked, your process can be re-entered by SendMessage calls from other processes. So, for me, reentrance (in general) has also something to do with recursion.

[Wolf P.]

I added a toc to the page. (and to the "wiki syntax help":http://developer.qt.nokia.com/wiki/WikiSyntax too)