Suspend/resume a pthread thread
Wed May 12 02:52:00 GMT 2010
> -----Original Message-----
> From: Keisial [mailto:firstname.lastname@example.org]
> Bharath Ramesh wrote:
> >> From: Petr Baudis [mailto:email@example.com]
> >> On Tue, May 11, 2010 at 12:38:17AM -0400, Bharath Ramesh wrote:
> >>> I believe currently there exists no such pthread API like
> >>> pthread_continue/resume/suspend. What would be the ideal way to
> >>> suspend/resume a thread from another thread in a multi-threaded
> >> application.
> >>> Of course for this to work one should ensure that program will not
> >>> deadlock, this is something I can guarantee as a programmer.
> >>> One cannot use
> >>> pthread_kill as no thread can individually block SIGSTOP.
> The fact that SIGSTOP can't be blocked guarantees that it gets
> Why do you need to block SIGSTOP in order to use pthread_kill?
I don't want to suspend my entire application, just particular threads.
> >>> I was wondering if
> >>> any API similar to one present in HP-UX  exists for NPTL.
> >> I don't really see a great value in this (after all, thread
> >> cancellation
> >> is already extremely hairy stuff in itself, introducing more of this
> >> stuff sends chills down my spine), can you present some practical
> >> usecase that would benefit from this and could not be easily done
> >> otherwise?
> >> Usually, threads are fairly self-contained tasklets that don't
> >> need to be stopped temporarily at random points, or revolve around a
> >> certain loop and can easily check for suspend condition at the loop
> >> head.
> > The following are some use cases that come to mind immediately:
> > 1) Debugging information in multi-threaded cases. Once could use the
> > of thread suspend and resume to print out debugging information in a
> > multi-threaded application if one of threads hit a specific
> > 2) In a event based producer-consumer system, I could have one thread
> > in busy loop checks for events queuing them for the appropriate work
> > At times there could be specific time critical event would have to be
> > handled immediately. In such a scenario one worker thread could be
> > and the producer thread can queue the event for another thread which
> > resume the stopped thread once the specific event has been handled.
> This way
> > the producer thread could still queue other events without having it
> > handle such events.
> I don't see why you need to stop the running threads. Seems like a way
> to ensure
> a different thread gets a share of CPU. You should be able to achieve
> that using
> setschedparam and/or setaffinity.
Please correct me if wrong, if a thread is executing I would have to wait
for it complete its time slice before the other thread can execute. If I had
a way to suspend it, then if it was executing I could "preempt" it and then
execute the other thread.
> > 3) This probably comes from research perspective, with ever
> increasing core
> > count speculative execution makes more sense now. For one to ensure
> no data
> > race occurs the thread that wins the execution can see that the other
> > threads are stopped commit its changes then set the other threads to
> > cancelled.
> > 4) The particular use case that I am interested is in high-
> > computation. The reason I use this is that based on certain
> > event I would like to stop the main computational thread so that I
> can setup
> > certain states for the main computational thread which it would check
> > infrequently. I cannot achieve this using locks.
> Have you tried using a signal handler?
Currently, I am using SIGUSR1 to handle this case. I cannot have multiple
threads suspend an already suspended thread as if I am already inside the
handler the signal wouldn't be delivered. I would want my thread only to
resume after all the threads that issued the suspend send it a resume.
> > I don't have any internal knowledge about NPTL, if this of interest I
> > probably take out sometime to see how this can be achieved if someone
> > guide me in this.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4440 bytes
Desc: not available
More information about the Libc-help