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