locking /dev/audio

[Loki Jorgenson Rm421]

	Is there any reason why I should not be able to use lockf() on
/dev/audio?

	I haven't done extensive error-checking but the circumstances
don't make it very easy.  Basically, it is happens that one process may
try to write to /dev/audio while another is reading (or vice versa).  So
I have tried to implement advisory locking in both processes with

lockf(audio,F_LOCK,0);
... stuff ...
lockf(audio,F_ULOCK,0);

around any attempts to read/write/ioctl /dev/audio (Note: /dev/audio has been 
open()'d O_RDWR by both processes earlier).
	
	One of the side-effects of lockf(...,F_LOCK,...) is that it
sleeps if there is already a lock on the file.  This is desirable.
What apparently happens is that at least one call to lockf() succeeds
before both processes later fall asleep having failed to apply locks.
It seems like the first F_ULOCK attempt fails after the first F_LOCK has been 
applied (both within the same process).  However, this is conjecture.

	What I am really asking is if there is any reason why /dev/audio
should be considered a special file (which lockf won't work on) and what
alternatives are available if so?

Thanks,
                             __          __
Loki Jorgenson              / /          \ \  node:  loki at Physics.McGill.CA
Grad, Systems Manager      / //////  \\\\\\ \ BITNET: PY29 at MCGILLA
Physics, McGill University \ \\\\\\  ////// / fax:   (514) 398-8434
Montreal Quebec CANADA      \_\          /_/  phone: (514) 398-7027