Discussion about "Threads, Events and QObjects" article
-
[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.
-
[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#DESCRIPTIONNow that you're telling me, perhaps should I change that term?
-
-
Sorry for this naive comment. Finally I found that this is Qt terminology: http://doc.qt.nokia.com/latest/threads-reentrancy.html
-
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 -
[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.
-
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 :-)
-
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?
-
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. -
[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.
-
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.