Introduce down_nowait()

I planned on removing the much-disliked down_trylock() (with its backwards return codes) in 2.6.27, but it's creating something of a logjam with other patches in -mm and linux-next.

Andrew suggested introducing "down_nowait" as a wrapper now, to make the transition easier.

Signed-off-by Rusty Russell <[email protected]>

Cc Andrew Morton <[email protected]>

Cc Christoph Hellwig <[email protected]>

Cc Matthew Wilcox <[email protected]>

Cc Stephen Rothwell <[email protected]>

diff -r 92664ae4130b include/linux/semaphore.h

include/linux/semaphore.h +5 -0

@@ -48,4 +48,18 @@ extern int __must_check down_timeout(str
 extern int __must_check down_timeout(struct semaphore *sem, long jiffies);
 extern void up(struct semaphore *sem);
 
+/**
+ * down_nowait - try to down a semaphore, but don't block
+ * @sem: the semaphore
+ *
+ * This is equivalent to down_trylock(), but has the same return codes as

Quoted 7 lines · On Wed, 21 May 2008 16:00:15 +1000 Rusty Russell <[email protected]> wrote:

Andrew suggested introducing "down_nowait" as a wrapper now, to make the transition easier.
...
+/**
+ * down_nowait - try to down a semaphore, but don't block
+ * @sem: the semaphore
+ *

Actually, I don't thing down_nowait() is a terribly good name, because it doesn't tell the reader anything about what to expect from the return value. Does a non-zero return mean that down_wait() acquired the lock, or does it not? Something like down_try() would be better, because if it returns 1 we can say "ah, the trying succeeded".'

Except "down_nowait" doesn't have "try" in its name. down_try() would be better?

Subject: [PATCH] Introduce down_try()

I planned on removing the much-disliked down_trylock() (with its backwards return codes) in 2.6.27, but it's creating something of a logjam with other patches in -mm and linux-next.

Andrew suggested introducing "down_try" as a wrapper now, to make the transition easier.

Quoted 6 lines · Rusty Russell

Subject: [PATCH] Introduce down_try()

I planned on removing the much-disliked down_trylock() (with its backwards return codes) in 2.6.27, but it's creating something of a logjam with other patches in -mm and linux-next.

Quoted 2 lines

Andrew suggested introducing "down_try" as a wrapper now, to make the transition easier.

I must be missing something critical, but what's the logjam this is causing?

Daniel

The patches to change down_trylock to down_try touch a heap of files, which are also touched in other people's trees. If this patch goes upstream, those people rewriting that code can use down_try in their rewrite, and I can throw mine away.

Quoted 4 lines · Rusty Russell

The patches to change down_trylock to down_try touch a heap of files, which are also touched in other people's trees. If this patch goes upstream, those people rewriting that code can use down_try in their rewrite, and I can throw mine away.

Seems like it's too much trouble.. I mean, we're removing semaphores anyway and down_trylock with them. I'll agree with Andrew down_trylock removal is pretty glacial. It's cause there aren't many of them and most of the ones I've looked at are in strange locking schemes, which makes them difficult to remove..

I'm not against your changes, but if it's going to cause problems I'd rather people focus on mutex_trylock instead.

Actually, I don't thing down_nowait() is a terribly good name, because it doesn't tell the reader anything about what to expect from the return value. Does a non-zero return mean that down_wait() acquired the lock, or does it not? Something like down_try() would be better, because if it returns 1 we can say "ah, the trying succeeded".

Quoted 5 lines · Andrew Morton

Actually, I don't thing down_nowait() is a terribly good name, because it doesn't tell the reader anything about what to expect from the return value. Does a non-zero return mean that down_wait() acquired the lock, or does it not? Something like down_try() would be better, because if it returns 1 we can say "ah, the trying succeeded".

Actually, it does,

and the kerneldoc comment explains it in every detail for those who need to read it up.

Then again semaphores and on their
way out, and I really hate the kind of churn this thing introduces at this moment. Please let all the semaphore to completion/mutex/other construct change settle for a while, and with a little chance this gem will just go away entirely.

The number of down_trylocks in rc3 is 51 and the number of down_trylocks and down_nowaits in -mm is 47. So progress is pretty glacial.

Anyway, yes, I agree that the whole effort is a bit dubious and that the time could be better directed to semaphore eliminations.