On Thu, 2 Nov 2000, Petr Vandrovec wrote:
> 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 you use a rw semaphore taken for writing by two writers, it
On Thu, 2 Nov 2000, Petr Vandrovec wrote:
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 you use a rw semaphore taken for writing by two writers, it
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
>
I posted yesterday about a problem in 2.4.0-test10 regarding *LONG*
stalls in 'ps' and 'vmstat'. After a conversation with Rik van Riel, it
seems that this may be caused by contention over the mmap_sem semaphore.
I have a question about the fairness of the semaphore implementation
that may be
I posted yesterday about a problem in 2.4.0-test10 regarding *LONG*
stalls in 'ps' and 'vmstat'. After a conversation with Rik van Riel, it
seems that this may be caused by contention over the mmap_sem semaphore.
I have a question about the fairness of the semaphore implementation
that may be
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
6 matches
Mail list logo
