This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Suspend/resume a pthread thread


> -----Original Message-----
> 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. 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.

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.

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.

> 
> > I could
> > probably use something like SIGUSR1/SIGUSR2 to sched_yield till the
> > condition for resume is satisfied, this would only move my thread to
> the end
> > of the ready queue. I wanted to know if there was any better way of
> > achieving this.
> 
> Why not wait on a semaphore or a condvar for the green light instead of
> looping sched_yield()?

The sched_yield() was a quick and dirty way for me to achieve this.
Semaphores would be better way rather than looping around sched_yield().

Regards,

Bharath

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]