Thread within a thread
Raseel
invocation ?
If I correctly pthread_join() the new thread from the calling thread,
does it make good design sense ?
David Schwartz
> Is it possible to call a thread (pthread) from within a thread
> invocation ?
There is no other way to do it. If code is running, it's a thread
that's running it.
> If I correctly pthread_join() the new thread from the calling thread,
> does it make good design sense ?
You can call 'pthread_join' from any thread that wants to wait for any
other non-detached thread to complete.
DS
Chris M. Thomasson
news:2ec36658-cce9-4b00...@u9g2000pre.googlegroups.com...
On May 14, 10:33 pm, Raseel <raseelbha...@gmail.com> wrote:
> > Is it possible to call a thread (pthread) from within a thread
> > invocation ?
> There is no other way to do it. If code is running, it's a thread
> that's running it.
;^)
Chris M. Thomasson
news:5b11295d-3097-4e35...@d19g2000prh.googlegroups.com...
> Is it possible to call a thread (pthread) from within a thread
> invocation ?
> If I correctly pthread_join() the new thread from the calling thread,
A thread does not have to be joined with the thread that created it. Thread
A can create thread B which can be joined with thread C.
> does it make good design sense ?
What type of algorithm are you using threads to solve?
Raseel
> "Raseel" <raseelbha...@gmail.com> wrote in message
Basically I am invoking a thread which eventually needs to send across
some files.
Since this might take some time, I would like to invoke a thread so
that the "send"ing procedure can take it's own sweet time, while the
original thread can continue with it's task.
Makes sense ?
Dave Butenhof
> Is it possible to call a thread (pthread) from within a thread
> invocation ?
One doesn't "call" a thread. A thread is an independent call stack. You
can interact with that thread directly or indirectly using APIs and
shared data. You can request termination, or join with it. You can't
"call into it". I suspect you didn't even mean that question literally,
but it's difficult to guess exactly what you did mean.
Any thread can create a thread. Any thread can join with (or otherwise
control) any thread for which it has a pthread_t handle. (Using pthread
APIs; although there are many other ways to interact with threads that
don't involve explicit thread identity; for example waiting on a
condition variable that one of many threads might signal or broadcast
when terminating.)
And, as David Schwartz said, "we're all threads in here". Conceptually,
at least, for all practical purposes, a "process" in any system
supporting threads is nothing but a passive resource container with an
address space, file numbers, (etc.), and a set of threads. (The Mach
microkernel architecture makes this particularly clear, but it's true
even on Linux where pthread_create makes a PROCESS that just shares some
context with its parent.)
Only threads are executable. One thread happens to have run the process
startup code and called main(), and on return will terminate the process
by calling exit(); but that's just a matter of its call stack, NOT
anything special about the execution context. It's just another thread.
(And, in particular, if it terminates by calling pthread_exit(), or
through cancellation, other threads will continue just fine without it.)
> If I correctly pthread_join() the new thread from the calling thread,
> does it make good design sense ?
Well, now, that's a big question and we don't have sufficient
information to answer it. It's POSSIBLE. It's LEGAL. And there are
certainly many cases where it makes perfect sense and is even a good
idea. But whether it makes "good design sense" for YOUR purposes depends
on what that purpose is.
Threads, unlike processes, have no innate "parent child" relationship,
and there are no security boundaries between them. A process can only
wait() for its children; but if a thread has a pthread_t value, it can
join with the corresponding thread. (Or cancel it, set its priority, etc.)
David Schwartz
> > If I correctly pthread_join() the new thread from the calling thread,
> > does it make good design sense ?
> Well, now, that's a big question and we don't have sufficient
> information to answer it. It's POSSIBLE. It's LEGAL. And there are
> certainly many cases where it makes perfect sense and is even a good
> idea. But whether it makes "good design sense" for YOUR purposes depends
> on what that purpose is.
Exactly.
Generally, there are only two good reasons to call pthread_join:
1) You cannot make further forward progress until some other thread
finishes what it's doing. In this case, you call pthread_join as a way
to wait for the other thread to finish what it was doing. For example,
your application is ready to terminate, but cannot do so until
outstanding tasks are finished. The thread you are joining is doing
some such task and you will terminate the application when you are
done.
2) You already know that a thread has finished its job and either
terminated or is about to terminate. The thread was not detached
(perhaps so you could cancel it or for some other reason), and it's
your job to 'clean up' after the thread by joining it.
IMO, neither of these are particularly good reasons to use
pthread_join and there are almost always better solutions. My basic
gripe is that thread termination has no application-visible effects
(*) so there's no rational reason to wait for it. Wait for whatever
the thread was going to *do* instead. However, if pthread_join happens
to do exactly what you need, there's no good reason not to call it.
DS
* This is not literally true, and this does create some narrow
exceptions were pthread_join is actually your best or even only
solution. For example, waiting for all TSD destructors to finish,
should you have need to do that, can basically be done no other way.
Chris M. Thomasson
> Makes sense ?
So far, yes. BTW, how many of those threads do you find yourself creating?
Just a couple, or perhaps hundreds?
Chris M. Thomasson
news:gujmth$30s$1...@usenet01.boi.hp.com...
> Raseel wrote:
>> Is it possible to call a thread (pthread) from within a thread
>> invocation ?
>
> One doesn't "call" a thread.
[snip sage advise]
Hi Dave! its nice to read your advise once again.
Thank you for keeping this humble little group alive with your expert
knowledge!
:^D
Chris M. Thomasson
news:xGOPl.58283$bi7....@newsfe07.iad...
BTW, this group seems to be slowly crapping out as traffic is WAY down.
Well, perhaps the new many-core processors on the horizon will spark
conversation once again?
BTW, thank you for teaching SenderX a lesson he will never forget...........
;^)
Szabolcs Ferenczi
Practically you can do anything with thread create and join since it
is the unstructured form of process handling (forking). Note that the
thread is a logical process too although a light weight one. Thread
create is something like the goto statement in the sequential parts of
the program.
If you aim at good design, you are better off using thread create/join
to implement the structured way of process handling. Once upon a time
it was called cobegin-coend but nowadays, according to the modern way
of renaming things to make the illusion there is something new, it is
called fork-join in the Java world. With disciplined use of pthreads
you can implement it easily.
The main message is that any good design is structured with respect to
thread create/join too even if the unstructured thread creation has to
be used.
Best Regards,
Szabolcs
Bartlomiej Jacek Kubica
> ---
> Generally, there are only two good reasons to call pthread_join:
> ---
> IMO, neither of these are particularly good reasons to use
> pthread_join and there are almost always better solutions.
> ---
Well, it seems to me that it is quite natural in case of a master-slaves,
master-workers or whatever we call it, to do it with joining:
1. The master starts n workers in a loop.
2. The master waits for the workers to complete their jobs.
IMHO, it seems quite appropriate to join the threads in the second loop.
Obviously, we can also create threads as detached and put a barrier, but
would it really be better in any way ?
Best regards
Bartlomiej
David Schwartz
<bkub...@mion.elka.pw.edu.pl> wrote:
> Well, it seems to me that it is quite natural in case of a master-slaves,
> master-workers or whatever we call it, to do it with joining:
I disagree.
> 1. The master starts n workers in a loop.
You mean the master assigned 'n' jobs.
> 2. The master waits for the workers to complete their jobs.
You mean the master waits for the jobs to complete.
> IMHO, it seems quite appropriate to join the threads in the second loop.
It is totally inappropriate. What if the threads want to go do
something else? Why force the threads to terminate just to tell the
master the threads finished the jobs they were doing? The master wants
to wait for the jobs to finish, not for the threads that did them to
terminate.
> Obviously, we can also create threads as detached and put a barrier, but
> would it really be better in any way ?
It would be much better to queue the jobs the master is waiting for to
some kind of thread pool and then wait for the jobs to complete. That
way, the most efficient threads could do the jobs rather than forcing
lots of bogus context switches.
For example, suppose there are 10 small jobs and one CPU. Creating 10
threads forces at least 10 context switches, along with all the
overhead of creating and destroying those threads. A single thread
could do all ten jobs.
DS
Dave Butenhof
> "Chris M. Thomasson" <n...@spam.invalid> wrote in message
> news:xGOPl.58283$bi7....@newsfe07.iad...
>> "Dave Butenhof" <david.b...@hp.com> wrote in message
>> news:gujmth$30s$1...@usenet01.boi.hp.com...
>>> Raseel wrote:
>>>> Is it possible to call a thread (pthread) from within a thread
>>>> invocation ?
>>>
>>> One doesn't "call" a thread.
>>
>> [snip sage advise]
>>
>> Hi Dave! its nice to read your advise once again.
>>
>> Thank you for keeping this humble little group alive with your expert
>> knowledge!
I read fairly frequently, but don't always post. I think there are a lot
of reasons, and they're somewhat synergistic. I'm busier with "other
stuff", there is as you say probably less heavy traffic here than there
was, and, perhaps most important, there are other active posters here to
rush in with good advice in response to any questions. I try to avoid
"yeah, what he said" kind of posts, except where I need to correct
(rare) or where I feel that I can offer an additional useful level of
detail that was omitted; which often leaves me with nothing to add.
>> :^D
>
> BTW, this group seems to be slowly crapping out as traffic is WAY down.
> Well, perhaps the new many-core processors on the horizon will spark
> conversation once again?
I see a fairly consistent stream of questions, but most are
non-controversial "newbie" questions, or philosophical design issues
that may spark some moderate knuckle whacking and a little discussion,
but aren't particularly world shattering. That's probably the way it
should be, most of the time.
If you think about it, the times when the group has been busy are often
times when 1 or 2 discussion threads have devolved into long strings of
name calling and innuendo, often where one of our pet weirdos has made
some totally off the wall statement that others simply can't let stand.
It's BUSY, but not very productive, and probably terrifies any newbies
into going elsewhere for help.
I'm much more happy with a sedate pace of real questions; mixed with
ongoing "scholarly debate about the pros and cons of AMDs ASF, or
whatever other "edge of the practice" (if not necessarily "state of the
art") stuff is going on in the world of concurrent programming. It's
easier to keep up this way, and nobody's feeling particularly
threatened. That's good.
> BTW, thank you for teaching SenderX a lesson he will never
> forget...........
Yeah, well, those were interesting times. Hey, this SenderX guy was
doing interesting things in lock-free algorithms, and had some good
ideas, but a lousy attitude. I can confidently say that he's matured
really well... although he still has a tendency to "post first, think
later" and often ends up, um, replying to himself with additions or
corrections. ;-)
Bartlomiej Jacek Kubica
> ---
>> IMHO, it seems quite appropriate to join the threads in the second loop.
>
> It is totally inappropriate. What if the threads want to go do
> something else? Why force the threads to terminate just to tell the
> master the threads finished the jobs they were doing? The master wants
> to wait for the jobs to finish, not for the threads that did them to
> terminate.
Well, it's probably a good subject to start a holy war about. ;-)
There can be different applications and different software
architectures/designs. I'm mostly involved in parallel computations and a
fork-join structure seems natural there (at least to me).
What do you mean that a thread ``wants'' to do sth else ? A thread is
created to do a job. It does not have a freewill. ;-)
If there is another work to be done, it can be done by another thread - it
is difficult to discuss it on such level of abstraction, but it seems so,
to me.
We have a different situation, when we create a server that is going to
work for several clients - there a thread pool and assigining work without
thread re-creation would be natural. But it depends on the situation.
> ---
> It would be much better to queue the jobs the master is waiting for to
> some kind of thread pool and then wait for the jobs to complete. That
> way, the most efficient threads could do the jobs rather than forcing
> lots of bogus context switches.
It might be a good way, but it seems to me that most popular APIs don't
have a simple interface to do this. And pthread_create/pthread_join is
obviously present in POSIX threads and has natural relatives for other
APIs.
> For example, suppose there are 10 small jobs and one CPU. Creating 10
> threads forces at least 10 context switches, along with all the
> overhead of creating and destroying those threads. A single thread
> could do all ten jobs.
Again, we could discuss it in several details.
It seems to me that if we can verify that we have only one processor and
that it is best to create only one thread, we can as well assign all work
to this thread.
Though, obviously if we consider e. g. an application like a web server,
you'd be perfectly right.
Best regards
Bartlomiej Kubica
Chris M. Thomasson
"Dave Butenhof" <david.b...@hp.com> wrote in message
news:gurpn3$pih$1...@usenet01.boi.hp.com...
> Chris M. Thomasson wrote:
>> "Chris M. Thomasson" <n...@spam.invalid> wrote in message
>> news:xGOPl.58283$bi7....@newsfe07.iad...
>>> "Dave Butenhof" <david.b...@hp.com> wrote in message
>>> news:gujmth$30s$1...@usenet01.boi.hp.com...
>>>> Raseel wrote:
>>>>> Is it possible to call a thread (pthread) from within a thread
>>>>> invocation ?
>>>>
>>>> One doesn't "call" a thread.
>>>
>>> [snip sage advise]
>>>
>>> Hi Dave! its nice to read your advise once again.
>>>
>>> Thank you for keeping this humble little group alive with your expert
>>> knowledge!
>
> I read fairly frequently, but don't always post. I think there are a lot
> of reasons, and they're somewhat synergistic. I'm busier with "other
> stuff", there is as you say probably less heavy traffic here than there
> was, and, perhaps most important, there are other active posters here to
> rush in with good advice in response to any questions. I try to avoid
> "yeah, what he said" kind of posts, except where I need to correct (rare)
> or where I feel that I can offer an additional useful level of detail that
> was omitted; which often leaves me with nothing to add.
Very good points.
>> BTW, this group seems to be slowly crapping out as traffic is WAY down.
>> Well, perhaps the new many-core processors on the horizon will spark
>> conversation once again?
>
> I see a fairly consistent stream of questions, but most are
> non-controversial "newbie" questions, or philosophical design issues that
> may spark some moderate knuckle whacking and a little discussion, but
> aren't particularly world shattering. That's probably the way it should
> be, most of the time.
Humm... Well, yes I do have to agree. IMVHO, I do enjoy helping newbie's out
with their problems. However, I do miss the fairly "frequent" hard core
discussions on advanced synchronization algorihtms. I have really enjoyed
all of the discussions I have had with Dmitriy Vyukov. His Relacy project
has been a joy to work with!
> If you think about it, the times when the group has been busy are often
> times when 1 or 2 discussion threads have devolved into long strings of
> name calling and innuendo, often where one of our pet weirdos has made
> some totally off the wall statement that others simply can't let stand.
Oh boy. Yes. I think the most recent phrase that went something like:
"A condition variable cannot be used to wait on events"
and sparked a plethora of those nasty threads... However, I do remember a
certain "person" who was advocating a religion with dogma that went
something like:
"lock-based algorihtms will __always__ be a 100,000x slower than a retarded
slug attempting to climb a 50,000 foot mountain of sea salt! LOL!!!"
That kind of non-sense/bullshi% did not help anything/anybody in any way
shape or form! Counter productive to say the least; ouch...
A clever mix of lock-based and non-blocking algorihtms can give the best of
both worlds. For instance, an eventcount, which uses locks, is basically the
only way to enhance non-blocking algorihtms with conditional blocking
abilities; heck, even a futex is eventcount like. A lock-free
stack/queue/whatever can now block on boundary conditions such as
"full/empty/ect". Locks to the rescue; big time! IMVHO, the eventcount is as
important to non-blocking algorithms as condition variables are to
lock-based algorihtms. I invented a fairly good algorihtm for an eventcount
and posted to this group here:
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/aa8c62ad06dbb380
IMVHO, this basically "proves" that a marriage between non-blocking and
lock-based can be a very beautiful thing indeed!
;^)
BTW, futexs aside, have you played around with eventcounts?
> It's BUSY, but not very productive, and probably terrifies any newbies
> into going elsewhere for help.
Agreed.
> I'm much more happy with a sedate pace of real questions; mixed with
> ongoing "scholarly debate about the pros and cons of AMDs ASF, or whatever
> other "edge of the practice" (if not necessarily "state of the art") stuff
> is going on in the world of concurrent programming. It's easier to keep up
> this way, and nobody's feeling particularly threatened. That's good.
Again. All good points. IMO, the recent AMD thread is very interesting.
Especially since the original inventors are posting. Also, AMD mentioned
that they are open to suggestions! I personally think that ASF has _major_
potential.
>> BTW, thank you for teaching SenderX a lesson he will never
>> forget...........
>
> Yeah, well, those were interesting times.
=^)
> Hey, this SenderX guy was doing interesting things in lock-free
> algorithms, and had some good ideas, but a lousy attitude.
No comment... ;^o
> I can confidently say that he's matured really well... although he still
> has a tendency to "post first, think later" and often ends up, um,
> replying to himself with additions or corrections. ;-)
Oh shi%! Well, I guess when he is thinking of a new algorithm/design,
perhaps he should code the darn thing up in Relacy, or something and
___then___ post it. That method should cut down on subsequent corrections...
But, when your excited, mistakes can and _will_ be made. Luckily he cares
enough to actually post corrections and document shortcomings...
;^/
Although, some of those algorihtms with posted corrections, are actually
fairly useful...
Yikes!
David Schwartz
<bkub...@mion.elka.pw.edu.pl> wrote:
> On Sun, 17 May 2009, David Schwartz wrote:
> > ---
> >> IMHO, it seems quite appropriate to join the threads in the second loop.
> > It is totally inappropriate. What if the threads want to go do
> > something else? Why force the threads to terminate just to tell the
> > master the threads finished the jobs they were doing? The master wants
> > to wait for the jobs to finish, not for the threads that did them to
> > terminate.
> Well, it's probably a good subject to start a holy war about. ;-)
> There can be different applications and different software
> architectures/designs. I'm mostly involved in parallel computations and a
> fork-join structure seems natural there (at least to me).
> What do you mean that a thread ``wants'' to do sth else ? A thread is
> created to do a job. It does not have a freewill. ;-)
I mean that there is something else to do. This thread could do it.
This thread is running. This thread has nothing else to do, since it's
about to terminate. There is absolutely no rational reason to
terminate the thread and force a context switch.
> If there is another work to be done, it can be done by another thread - it
> is difficult to discuss it on such level of abstraction, but it seems so,
> to me.
Of course, but that's inefficient. This thread is running. The
scheduler's job is to run the most efficient thread, the programmer's
job is to get the work done.
> We have a different situation, when we create a server that is going to
> work for several clients - there a thread pool and assigining work without
> thread re-creation would be natural. But it depends on the situation.
Name a situation where it makes more sense to terminate a thread and
make a new one do some work rather than not terminating the thread.
> > It would be much better to queue the jobs the master is waiting for to
> > some kind of thread pool and then wait for the jobs to complete. That
> > way, the most efficient threads could do the jobs rather than forcing
> > lots of bogus context switches.
>
> It might be a good way, but it seems to me that most popular APIs don't
> have a simple interface to do this. And pthread_create/pthread_join is
> obviously present in POSIX threads and has natural relatives for other
> APIs.
I don't really follow you. To use pthread_join, you have to make the
thread terminate somehow. So instead of making the thread terminate,
signal that the job is done and see if there's something else to do. I
don't know of any API that provides you back a pthread_t whose
termination you can wait for. (Though if there was, I'd say that's a
sub-optimal API, but if you're stuck with it, that's life.)
> > For example, suppose there are 10 small jobs and one CPU. Creating 10
> > threads forces at least 10 context switches, along with all the
> > overhead of creating and destroying those threads. A single thread
> > could do all ten jobs.
> Again, we could discuss it in several details.
> It seems to me that if we can verify that we have only one processor and
> that it is best to create only one thread, we can as well assign all work
> to this thread.
No, not so. The thread may block unexpectedly, say due to a page
fault. Stalling the process is not a good thing.
> Though, obviously if we consider e. g. an application like a web server,
> you'd be perfectly right.
You may be able to tolerate sub-optimal design in some projects but
not others, and where there's an advantage that makes the apparently
sub-optimal actually optimal, then go for it. Easy of design,
maintainability, reuseability, and so on can all outweigh performance
in some cases. However, this is a case where there are rarely any such
advantages.
DS
Markus Elfring
> non-controversial "newbie" questions, or philosophical design issues
> that may spark some moderate knuckle whacking and a little discussion,
> but aren't particularly world shattering.
Would it be useful to look into the following issues again?
- Protect against spurious wakeups
http://bugzilla.schleef.org/cgi-bin/bugzilla/show_bug.cgi?id=57
http://bugs.kde.org/show_bug.cgi?id=156800
http://sourceforge.net/tracker/?func=detail&atid=115063&aid=1942058&group_id=15063
- implementation check for "RTLock::release"
http://www.virtualbox.org/ticket/3346
Regards,
Markus
Szabolcs Ferenczi
> > I see a fairly consistent stream of questions, but most are
> > non-controversial "newbie" questions, or philosophical design issues
> > that may spark some moderate knuckle whacking and a little discussion,
> > but aren't particularly world shattering.
>
> Would it be useful to look into the following issues again?
>
> - Protect against spurious wakeups
> http://bugzilla.schleef.org/cgi-bin/bugzilla/show_bug.cgi?id=57
> http://bugs.kde.org/show_bug.cgi?id=156800
>
> - implementation check for "RTLock::release"
> http://www.virtualbox.org/ticket/3346
>
> Regards,
> Markus
May I call your attention to the simple condition variable test:
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/0ff7ac10adadee22
Best Regards,
Szabolcs
Chris M. Thomasson
news:fada81b2-f77b-4a9b...@c36g2000yqn.googlegroups.com...
> On May 25, 10:40 pm, Markus Elfring <Markus.Elfr...@web.de> wrote:
> > > I see a fairly consistent stream of questions, but most are
> > > non-controversial "newbie" questions, or philosophical design issues
> > > that may spark some moderate knuckle whacking and a little discussion,
> > > but aren't particularly world shattering.
> >
> > Would it be useful to look into the following issues again?
> >
> > - Protect against spurious wakeups
> > http://bugzilla.schleef.org/cgi-bin/bugzilla/show_bug.cgi?id=57
> > http://bugs.kde.org/show_bug.cgi?id=156800
> > http://sourceforge.net/tracker/?func=detail&atid=115063&aid=1942058&g...
> >
> > - implementation check for "RTLock::release"
> > http://www.virtualbox.org/ticket/3346
> May I call your attention to the simple condition variable test:
> http://groups.google.com/group/comp.programming.threads/browse_frm/thread/0ff7ac10adadee22
This simple condvar test works well.
Markus Elfring
Would you like to suggest any changes and adjustments for the source files of
the referenced software projects?
1. Dirac Video Compression - Schrï¿œdinger
2. WorkMan (CD player library) for KCompactDisc
3. Art of Illusion
4. VirtualBox
Regards,
Markus
Szabolcs Ferenczi
> > May I call your attention to the simple condition variable test:
>
> Would you like to suggest any changes and adjustments for the source files of
> the referenced software projects?
>
> 2. WorkMan (CD player library) for KCompactDisc
> 3. Art of Illusion
> 4. VirtualBox
If they fail the CV_TEST, they must be fixed.
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/0ff7ac10adadee22
Just check it out.
Best Regards,
Szabolcs
Markus Elfring
Do you recommend any concrete fixes for the source code of the mentioned
software examples?
Regards,
Markus
Chris M. Thomasson
> But, when your excited, mistakes can and _will_ be made. Luckily he cares
> enough to actually post corrections and document shortcomings...
>
> ;^/
BTW, `errno' is the reporter of errors in `sem_wait()'...
BARF..... BARF...
Do type code into newsreader!
Chris M. Thomasson
LOL!!!!!!!
Do NOT type code into newsreader!
WOW!!!
Dave Butenhof
Man, Chris, do you know how to prove a point or what? ... ;-)
Chris M. Thomasson
ROFL!!!! =^D