Maybe. Be careful that you don't get this wrong, though: you should NOT
think that semaphores are always mutexes, and there could be multiple
concurrent "up()" calls with semaphore counts > 1 etc, and I'd rather be
safe than sorry.
With the rule that you always wake somebody up when the count becomes
non-negative, you're at least safe. I'm not sure your new code is.
> down_trylock seems buggy because it always returns 1 and it won't make
> difference between the case that held the semaphore and the case that find
> the semaphore busy.
down_trylock has already _failed_.
It failed before the call - the down() has failed, and down_trylock just
has to correct the counts and then _unconditionally_ tell the world that
the failure happened.
That part of your patch is definitely bad. There's no way I'll ever add
this: you increment the semaphore count without waking people up, which is
just a sure way to set yourself up for nasty surprises.
Don't try to be clever when the trylock has already proven to have failed
once. Th ewhole _point_ of trylock is to try once and give up if it didn't
succeed.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/