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


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


> 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?

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


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