lkml.org 
[lkml]   [1999]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: new semaphores


On Sun, 29 Aug 1999, Andrea Arcangeli wrote:
>
> It seems to me that there's no need of wake-up the sleepers in the success
> path of __down(). If you get the semaphore nobody else can do progresses.
> You'll sure wakeup the sleepers some time soon in up().

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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.109 / U:1.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site