Read-write semaphores have their use and the current Linux implementation
(big reader/occasional writer) guarantees that the writer is not starved as
incoming read locks are put to sleep as soon as a write lock request comes
in, even if that is sleeping waiting for the old readlocks to be released
(unless the readers are holding the semaphore forever in which case this is
the programmers fault and not the rw semaphore implementations fault). [I
should add I only am familliar with the i386 implementation but I assume
the others are the same.]
The value of allowing multiple cpus to read the same data simultaneously by
far offsets the priority problems IMVHO. At least the way I am using rw
semaphores in ntfs it is. Readlocks are grabbed loads and loads of times to
serialize meta data access in the page cache while writelocks are a minute
number in comparison and because the data required to be accessed may not
be cached in memory (page cache page is not read in, is swapped out,
whatever) a disk access may be required which means a rw spin lock is no
good. In fact ntfs would be the perfect candidate for automatic rw combi
locks where the locking switches from spinning to sleeping if the code path
reaches a disk access. I can't use a manually controlled lock as the page
cache lookups are done via the mm/filemap.c access functions which are the
only ones who can know if a disk access is required or not so ntfs would
never know if it is going to sleep or not so unless the locks had
autodetection of whether to spin or sleep they would be useless.
I guess the point I am trying to make is that both rw semaphores and combi
locks are not bad per se but, as all other locking mechanisms, they should
be used in situations appropriate for their locktype and their
implementation...
Anton
-- "I've not lost my mind. It's backed up on tape somewhere." - Unknown-- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/