David Miller wrote: > From: Bob Breuer <breuerr@xxxxxx> > Date: Mon, 05 Jun 2006 23:59:29 -0500 > >> rw->lock in this case is the full 32-bit raw_rwlock_t, so a value of >> 0x000000ff is locked by a writer, 0x00000100 would be locked by a >> reader, and 0x000001ff would be locked by a reader and updating the counter. > > For a moment I thought you were right, but the spinlock acts > to atomicize the reader counter updates too. Is it ok if the can_lock macros are conservative and maybe return a false failure? > That lock could be set transiently, while decrementing the > reader counter down to zero. > > So it really does matter, and in fact you have to be even more > careful that I originally indicated. In fact I can't even see > how you can implement this %100 correctly. Even if can_lock() is 100% correct, there is no guarantee that the lock will still be available right after, only a trylock could give that kind of guarantee. > We simply can't tell if the spinlock is held because the writer > is trying to get in, or because a reader is holding is just to > increment or decrement the counter. If we can't tell, then be conservative and return 0. > If the reader count is zero, for example, the spinlock could be held > by a writer and we don't want to spin waiting for it to clear in that > case. If, however, the reader count is zero but the spinlock is > held so that a reader can increment the count, we would want to > spin waiting for the spinlock to release in that case. The can_lock macros never need to spin. Ok, how about a truth table to cover all combinations: reader count | wlock | lock value | write_can_lock | read_can_lock -------------+-------+------------+----------------+-------------- 1) 0 | 0 | 000000 00 | 1 | 1 2) 0 | not 0 | 000000 xx | 0 | 0 3) not 0 | 0 | xxxxxx 00 | 0 | 1 4) not 0 | not 0 | xxxxxx xx | 0 | 0 reader count and wlock are part the _same_ 32-bit value, therefore when we read the value we get a simultaneous snapshot of both and it must be in one of these 4 states. State 2 is a questionable state and could be caused by either a reader or a writer, therefore neither one can be guaranteed to succeed. State 4 would be a bigger concern because read_can_lock() could be expected to return true, but then again the caller must be expecting potential failure, or they wouldn't be checking with can_lock. - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
