On Wed, Nov 28, 2001 at 11:40:58PM +0100, Wolfgang Hoffmann wrote: > To me it's not clear why protecting a ringbuffer with a mutex > is evil. Is it simply the problem of "abuse", in the sense of one client > locks the mutex longer than necessary (i.e. longer than just > copying data to/from the buffer), or are there other reasons, > like overhead considerations due to locking/unlocking a mutex > (implementation details of pthread_mutex_...), or whatever?
There are cases where ringbuffer reader threads should never block. This means that if you have a single mutex setup for the whole ringbuffer you can have the following: (a) reader blocks, because writer has the mutex, bad! (b) reader uses pthread_mutex_trylock, fails because writer has the mutex, even though the request of the reader could be satisfied, also bad! > I'm curious about how you manage to safely access a ringbuffer > in a multithreading environment without using a mutex lock. I have an implementation in alsaplayer that uses mutexes but with a partitioned ringbuffer i.e. the ringbuffer has multiple segments which can be locked/unlocked on their own. The reader always uses pthread_mutex_trylock() so (a) will never occur. When choosing the partition size carefully you can be very confident that the reader and writer thread will always be accessing different segments, and thus not interfear with each other. The moment they do try to access the same segment the ringbuffer is considered to be depleted, which is perfectly valid. Andy _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
