Newbie Q: join vs critical section
Bruce Ingalls
advantage of using critical sections, over simply joining the threads,
and recreating them, after that section?
Hints:
Efficiency?
Thread Groups?
Other?
Conversly, what is the advantage of joining threads over critical sections?
I suspect that the answer to this one is code maintenance.
Bonus round:
I've seen mention of "fibers" on http://msdn.microsoft.com/
Do such exist in the Posix world?
David Schwartz
> Assuming that you are *not* using Thread Local Storage, what is the
> advantage of using critical sections, over simply joining the threads,
> and recreating them, after that section?
Creating and destroying threads is expensive.
> Conversly, what is the advantage of joining threads over critical sections?
> I suspect that the answer to this one is code maintenance.
I can't think of any.
> Bonus round:
> I've seen mention of "fibers" on http://msdn.microsoft.com/
> Do such exist in the Posix world?
No, though I've yet to hear of any actual use for them.
DS
David Butenhof
> Assuming that you are *not* using Thread Local Storage, what is the
> advantage of using critical sections, over simply joining the threads,
> and recreating them, after that section?
I don't understand the meaning of this question. Or rather, I can see a
number of possible meanings and I don't know which meaning you mean. ;-)
Rarely, if ever, can you build an application using only Thread Local
Storage (or Thread Specific Data, which is the POSIX equivalent). And if
you can, you're probably best off not bothering with threads, because,
well, if you're using only thread private data, you're not exactly SHARING
anything between threads, and that is the entire point of using threads.
Now, "critical section" can mean several things. In general, it means a
region of code dealing with synchronized (shared) data. I prefer to
encourage people to think in terms of the DATA (synchronization) rather
than the CODE ("critical section").
OR, since you said "thread local storage", which is most commonly associated
with the Win32 APIs for thread private data, by "critical section" you may
actually refer to the Win32 synchronization object that's really an
optimized mutex.
> Hints:
> Efficiency?
> Thread Groups?
> Other?
Thread groups? Now you're shifting over into Java.
> Conversly, what is the advantage of joining threads over critical
> sections? I suspect that the answer to this one is code maintenance.
If you're looking at "the big picture" (and that's not entirely clear from
the bundle of words you've tossed out), I could guess that you might be
trying to get at the distinctions between the "thread per client" model vs
a "work pool" model.
In the former, each "task" involves creating a thread, allowing it to run to
completion (competing for resources with other client threads), and then,
possibly, joining with it before taking on another task.
In the latter, each "task" involves queuing a request to be serviced by one
of a (variably sized) group of threads. Each worker will remove a request
from the queue, (with proper synchronization), service the request, and
then look for more work.
"Thread per client" is often considered easier for a "newbie" to write,
because, in principle, there may be little concern about shared data. In
fact, though, the unwary newbie is just as likely to get into trouble here
by, for example, passing each thread the address of local data that might
be freed or overwritten before the worker reads it, as they are to get in
trouble writing a basic thread pool.
Aside from this illusion of "simlicity", thread-per-client really has no
advantages whatsoever.
> Bonus round:
> I've seen mention of "fibers" on http://msdn.microsoft.com/
> Do such exist in the Posix world?
Fibers have nothing to do with threads. At least, no more than "read" and
"write" functions do. (Which is to say, they can be used within threads,
and may even work if used correctly.)
Fibers are a generalization of the original VMS "driver fork" mechanism,
which had been inherited by NT. The original driver fork was a mechanism by
which an I/O driver (written in assembly of course) could save some minimal
context to be continued later, generally at a lower hardware interrupt
level. It's a simple coroutine. Because NT drivers were generally written
in C rather than in assembly, the coroutine mechanism had to be cleaned up
and generalized. (VMS later did something similar to support high-level
language drivers, and they used the name "kernel process"... and I have to
say that the NT name is better.)
Some time ago, Microsoft found that some user-mode code (notably complex
I/O-bound database software) wanted to be able to use fibers. VMS, by the
way, has made a similar discovery recently and is also in the process of
making "kernel processes" more widely documented and available.
Either way, though, this is just simple and very limited co-routines, not
threads. You CAN switch multiple fibers on top of a thread, but you need to
keep your groups separate. That is, you cannot build a generalized 2-level
scheduler with kernel threads and fibers because a fiber's context isn't
complete: it depends on that of the thread in which it runs. (For example,
you mentioned Thread Local Storage... well, that is THREAD local storage,
not FIBER local storage, and if you were to switch a fiber from one thread
to another it'd now have different THREAD local storage. If the code cared,
that could be very bad.)
The closest to fibers you'll find in POSIX systems is the "*context" family
of functions. And, actually, that's very close. However, the standard
doesn't clearly define how (or if) these interact with threads, and you're
likely to run into portability problems if you try to use them. The best
answer is that if you're not REALLY sure exactly why you'd want (or need)
to do this, then you DON'T want (or need) to do this. Just forget all about
it! You'll be happier, and saner. (Well, OK, at least you'll probably be no
less happy or sane than now...)
--
/--------------------[ David.B...@hp.com ]--------------------\
| Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/