lkml.org 
[lkml]   [2008]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: semaphore: lockless fastpath using atomic_{inc,dec}_return
Hi,

>hi,
>
>not to ruin the party but... how is this lockless? An atomic variable
>is every bit a "lock" as a spinlock is... and very much equally
>expensive as well for most cases ;-(

Perhaps not the best the choice of words, I should have omitted the word
lockless. But it seems my understanding of lockless and yours is different.
And indeed, it's very expensive as a spinlock, but comparatively, is
only one operation, that if successful doesn't have to lock and then
unlock (that's why I called it lockless ...).
The mutex takes the same approach, however it uses it's own flavour of
atomic ops. What I'm really interested is if this brings any benefit in
terms of performance.


> And is this safe? It seems that we can always be rescheduled after
the atomic operation and
> interrupts can occur too. You need to tell us why this is safe in all
cases.

The slowpaths take care of that:
In 'down' slowpath after acquiring the spinlock the semaphore may have
been unlocked ("we can always be rescheduled after the atomic operation
and interrupts can occur too"), so we test again doing an
atomic_dec_return, like in fastpath case, if it fails we proced to wait
list and wait loop until someone wake us, if we get
task_interrupted/timeout we just abandon the wait list.
In 'up' slowpath after acquiring the spinlock we wake up one waiter,
however the list may be empty because we acquired the lock faster than a
possible waiter(s) or the waiter(s) abandoned the wait list, in such
case we atomic_inc the count to value that is >= 1 (taking into account
another 'up').



\
 
 \ /
  Last update: 2008-07-09 17:43    [W:0.043 / U:1.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site