On Sun, 16 Feb 2003 13:17:04 +0100, Erik Mouw wrote:
> The volatile keyword only tells the compiler:please load this variable
> everytime you read it, cause it might have been changed by an external
> source. It doesn't tell *anything* about writing to that variable.
> Suppose you have a variable i that tells you how many elements are in
> the buffer. What could happen without proper locking is:
> [...]
> So it looks like there are two elements in the buffer, while there is
> only one. With proper locking of variable i, this wouldn't have
> happened.
Actually the circular buffer case (1 producer, 1 consumer) works out
quite nicely without locking, simply because you don't need the extra
variable to count elements: head and tail together with the buffer size
give you all the needed info.
Worst case scenario: a thread is preempted after producing/consuming
data and before updating the head/tail pointers. But this only tricks
the other thread into seeing less data/free space than available. No
real damage.
All you have to do is make sure the head & tail updating and wrapping is
done atomically. And declare them volatile, of course.
So, it seems a safe bet after all (btw, Alessandro Rubini is presenting
this method in "Linux Device Drivers 2nd Edition").
--
Florin Malita web: http://www.malinux.net
public key: http://www.malinux.net/data/fmalita.gpg
This is a digitally signed message part