[lkml]   [2000]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: mmap_sem (and generic) semaphore fairness question
On  2 Nov 00 at 13:51, David Mansfield wrote:
> Is it possible for the following to happen repeatedly, keeping B from
> ever aquiring S.
> 1) Resource becomes available.
> 2) A is 'runnable' and is given an entire timeslice.
> 3) schedule() to A
> 4) A releases S
> 5) A returns to userspace
> 6) A uses much less than entire timeslice doing calculation
> 7) A needs some resource again
> 7) A enters kernel and aquires S
> 8) A sleeps on resource, rest of timeslice not used, A's 'goodness'
> isn't messed up.
> 9) goto 1.
> In this scenario, as long as A never uses it's full timeslice, B will
> never get to aquire S.

Yes, it can happens. It for sure happens in ncpfs - as ncpfs uses
ping-pong protocol, and I'm lazy to use different thing than semaphore,
connection to server is guarded by semaphore.

If one task does long read/write, nobody else can perform any operation
on mountpoint (these processes are listed in "D", as usual). As soon as
copying task pauses (writting readed data to another FS, pagefault), other
of competing tasks starts... If you'll start two copies in parallel, each
task usually copies each file without any progress on other task. After
copying one file, other task starts copying...

For now I solved it by adding second processor into the box ;-)
But if anybody has easy (or nice) implementation of fair semaphore,
or an idea how to fix it, I'd like to put it into ncpfs...

Probably creating safe_semaphore by moving sem->count++ from up()
(when up does __up_wakup) to __down_failed could work. But it is not
nice, as implementation of this idea requires spinlock in safe_up()
Best regards,
Petr Vandrovec
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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