Suspend/resume a pthread thread

Bharath Ramesh bramesh@vt.edu
Wed May 12 02:52:00 GMT 2010


> -----Original Message-----
> From: Keisial [mailto:keisial@gmail.com]
> Bharath Ramesh wrote:
> >> From: Petr Baudis [mailto:pasky@suse.cz]
> >>
> >> 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
> suspended.
> 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 [1] 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
> really
> >> 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
> feature
> > of thread suspend and resume to print out debugging information in a
> > multi-threaded application if one of threads hit a specific
> condition.
> >
> 
> > 2) In a event based producer-consumer system, I could have one thread
> which
> > in busy loop checks for events queuing them for the appropriate work
> thread.
> > At times there could be specific time critical event would have to be
> > handled immediately. In such a scenario one worker thread could be
> suspended
> > and the producer thread can queue the event for another thread which
> could
> > resume the stopped thread once the specific event has been handled.
> This way
> > the producer thread could still queue other events without having it
> to
> > 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
> be
> > cancelled.
> >
> > 4) The particular use case that I am interested is in high-
> performance
> > computation. The reason I use this is that based on certain
> asynchronous
> > 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
> could
> > probably take out sometime to see how this can be achieved if someone
> could
> > guide me in this.
> >


Regards,

Bharath
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4440 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-help/attachments/20100512/6ae6decc/attachment.bin>


More information about the Libc-help mailing list