Discussion about "Threads, Events and QObjects" article

[giesbert]

Hi,
thanks again, the article is really good, and I think, the pitfalls are clearer now. So looking fporward to your next article :-))

[Wolf P.]

bq. how to start, stop, join a thread under (at least) one major operating system;

Is joining threads such a common pattern?
I've always imagined threads as autonomous agents. This I was able to produce programmatically and at some point they were finished and forgotten. Whether or not the program code orphaned never seemed to matter to me.

[giesbert]

Joining threads is common, if you put parts of a bigger thing to threads to do that in paralell and want to wait for all results being finished. I know, it can also be done with QtConcurrent but some programs are older than QtConcurrent :-))

[dangelog]

[quote author="Wolf P." date="1292845577"]bq. how to start, stop, join a thread under (at least) one major operating system;

Is joining threads such a common pattern?
I've always imagined threads as autonomous agents. This I was able to produce programmatically and at some point they were finished and forgotten. Whether or not the program code orphaned never seemed to matter to me.[/quote]

It's a pattern, that's all. For instance, a possible use case is telling a worker thread to finish, then actually wait for it to end (by joining it), then deallocate some resources used by it.

[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?