Date: Fri, 7 Aug 1998 08:44:08 +1000 (EST) From: John Birrell <jb@cimlogic.com.au> To: shmit@kublai.com Cc: current@FreeBSD.ORG Subject: Re: Pthreads woes revisited. Message-ID: <199808062244.IAA02167@cimlogic.com.au> In-Reply-To: <19980806130122.38511@kublai.com> from Brian Cully at "Aug 6, 98 01:01:22 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Brian Cully wrote: > I've put together a small C program that demonstrates the problems > I described in my last message. You can find the program attached > to this message. > > Note the location of the `sleep(1)' call, it's important. If it moves > outside of the mutex lock/unlock bits, everything functions normally, > but if it gets called after the lock, but before the unlock, the first > signal is missed. Mutexes can be implemented with spinlocks so that a thread that is blocked trying to lock a mutex will burn CPU and only when it exceeds it's time slice will it be interrupted to allow another thread to run. For this reason, mutexes should only be used to gain exclusive access to something and a condition variable should be used to wait. The mutex associated with the condition variable _must_ be locked prior to calling the cond_wait function. The cond_wait function will queue the calling thread and unlock the mutex. When the condition variable is signalled, a waiting thread is granted access by locking the mutex just before the cond_wait function returns. The woken thread should do what it needs to do quickly, then unlock the mutex or wait again (causing the mutex to be unlocked). More than one thread may be woken, but only one will get access to the mutex - all the rest will burn CPU, so each thread must unlock the mutex as quickly as possible. Signalling a condition variable only serves to wake any thread that might be waiting. If a thread hasn't called a cond_wait function, it won't be in a position to be woken by the signal. The thread should not be coded to use the occurrence of a signal as the driving event. Instead there should be a variable that is protected by the mutex that is changed to be used as the event data. The thread that is being driven by this data then locks the mutex, checks the variable and if there is no event data there, it calls the cond_wait. If there _is_ data already there (as the result of another thread getting there before it), no wait is necessary and the thread just unlocks the mutex and goes about it's business. If you need to buffer more than one event, then the event variable needs to be an array or a list. Whatever the variable is, it must only be accessed (both read and write) with the mutex locked. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 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?199808062244.IAA02167>