Date: Wed, 21 Oct 1998 09:18:22 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: eischen@vigrid.com, lists@tar.com Cc: current@FreeBSD.ORG Subject: Re: Another Serious libc_r problem Message-ID: <199810211318.JAA23767@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
> >Yes, it seems that we need a method of disabling task scheduing > >while we enqueue the condition variable and call the thread > >kern scheduler. You should be able to do this by setting > >_thread_kern_in_sched = 1. Something like this (from > >pthread_cond_timedwait): > > [snip] > > >Calling _thread_kern_sched_state will end up clearing _thread_kern_in_sched, > >(and so will pthread_yield). The signal handler will not cause a > >reschedule when _thread_kern_sched_state is non-zero. > > Bear with me while I try to understand this. Between the time you > set _thread_kern_in_sched = 1 and the call to _thread_kern_sched_state > (or pthread_yield) you call pthread_mutex_unlock, which does a spinlock. > Also, before calling pthread_yield you also do a spinlock. Isn't a > spinlock a potential yield call to the kernel scheduler, which in > turn could set _thread_kern_in_sched = 0, and thus still leave you > vulnerable to the scheduling window you are concerned about? Yeah, good point. Although one could argue that the SPINLOCK in pthread_mutex_unlock shouldn't yield because other threads shouldn't be able to run at this point (_thread_kern_in_sched is non-zero) What we need are _thread_kern_sched_[un]lock() routines that wrap whatevers necessary to disable a signal from causing a thread switch. > If I understand, and I may not, what you are concerned about is that > after you unlock the condition spinlock, and before you yield to > the scheduler, you could be pre-empted, and that the condition could > be signaled (thus causing you to wait on a condition that has already > been signaled, a mistake?). Right, as someone else pointed out also. > The condition can only be signaled when > the condition spinlock is not held. So... why wouldn't you hold the > condition spinlock as long as possible (ie. after the mutex unlock) > and *then* set _thread_kern_in_sched = 1 after all the spinlocks have > been done? If the thread doesn't own the mutex, then you've got the condition variable locked while you're waiting for the pthread_mutex_unlock(). Since this falls into the category of "undefined behavior" it probably doesn't matter though. > Or, using your code snippet, why not this? > Yes this is OK and the way I had it originally before I felt a wave of AR'ness come over me. I think the part where the pthread_mutex_lock fails wrong (you don't need to lock the condition variable - it's already locked, and you don't need to disable thread scheduling and call pthread_yield). But I understand what you're saying. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810211318.JAA23767>