On Fri, 8 Apr 2005, Barry Pearce wrote:
 
>
> errr. no. here is the code snippet:
>
> persist = os.open(self.m_file, os.O_CREAT | os.O_EXCL | os.O_WRONLY, 0660)
>
> O_CREAT | O_EXCL ensures that any race is coped with by the operating syst
em
> kernel

you say "no" then say it is "coped with by the operating system" ;-)

this is flock(2), BTW

> - works equally well on mac/win32/unix/linux if two threads try it at
> precisely the same time one will win one will fail - the failed one simply
> re-evaluates the random and tries again. As yet though I have yet to see a
> collision on my code...I could only test by manufacturing the situation.
> 
>
> Fair do. But its not complex - given that part of the day job is linux ker
nel
> development - locking is not that bad!!! 

Well, may be how the actual locking is done in the OS isn't complex
(though I believe it actually has to be supported in hardware).

The messy part is that different types of locks beave differently when it
comes to the same process or its children accessing the same lock, and on
top of that the definitions may differ across different OS's. E.g. I don't
think flock would be usable in a multi-threaded environment since appying
a new lock from the same process is a noop. Also while flock is a
lock-per-file, an fcntl(2) lock can lock regions of a file... Then there
are SysV IPC semaphores which behave differently - finding and correctly
using the locks is the problem that the APR solves.

Grisha

[ Post a follow-up to this message ]