> > Yes. This is one of the problems with semaphores. BTW, why not using file
> > locking instead of it? It has much cleaner and richer semantics and almost
> > none of the problems semaphores have.
not terribly good portability, according to
/usr/src/linux/Documentatino/mandatory.txt , for mandatory locks?
advisory locks can be used, but then you only have a single such lock
available per file. if you need to use several locks, you need to keep
several files open, and since there's a limit on file descriptors per
process, this is not scaleable.
as to oded's reply:
> I don't think its an option I have for the current implementation - it's
> file IO, and should be much slower, right ?
well, i'm not sure that usage of locks performs any file I/O (after all,
all the locks data is kept in memory, not on disk, as this is NOT
persistent data). however, looking at the kernel's sources, it seems that
at least the implementation of mandatory locks would be less efficient
then that of semaphores. the locks on a file are kept as a linked list,
and sometimes get traversed - thus, if you have many locks active on a
single file, that'll be less efficient then using semaphores.
as for advisory locks (handled using the flock() syscall) - there is also
a linked list of locks kept on a file. however, if you'll only use
exclusive locks, there could be only one lock in this list at any given
time. and there is no file I/O during those operations.
--
guy
"For world domination - press 1,
or dial 0, and please hold, for the creator." -- nob o. dy
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
