Rusty Russell wrote:
> On 18 Mar 2002 20:05:22 -0800
> Ulrich Drepper <drepper@redhat.com> wrote:
>
>
>>On Mon, 2002-03-18 at 19:28, Rusty Russell wrote:
>>
>>
>>>What do you WANT in a kernel primitive then? Given that we now have mutexes,
>>>what else do we need to make pthreads relatively painless?
>>>
>>I think wrt to the mutexes only wake-all is missing. I don't think that
>>semaphore semantic is needed in the kernel.
>>
>
> And have all the waiters exit with errno = EAGAIN? ("You didn't get it but
> someone wanted you all woken").
>
That's a joke, isn't it? ;-)
We can return -1 with errno=ELOCKBREAK if the process holding the lock
dies.
Why don't we need a semaphore in the kernel?
There is open_sem() for POSIX named semaphores. The SysV interface
is there - and it's far more ugly.
in linuxthreads we have:
sem_t *sem_open(const char *name, int oflag, ...)
{
__set_errno (ENOSYS);
return SEM_FAILED;
}
Well, mutexes are not semaphores. Why not have fusema or fuma?
They are good for thread pools where you want several workers.
> It can be done, I'd have to see if is sufficient to implement pthreads.
>
I don't see the necessity for wake_all except for the barrier case.
A condvar implies, that when successfully returning, the thread
owns the mutex. So even in the case of cond_broadcast, only one thread
will get the mutex - the others will get blocked on that.
The only reason for cond_broadcast I can think of, are implementations
that wouldn't wake_up the highest priority waiting thread. So with
a broadcast all will be woken up and try to acquire the lock.
The waiters will NOT return without the mutex locked except on ETIMEDOUT
(when the thread gets cancelled, the cancelation handler will be called
and the thread will die).
It's also written in the spec, that when you want "predictable scheduling"
the caller of signal/broadcast _has_to_ hold the mutex. On release of
the mutex all other threads will race for it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Mar 23 2002 - 22:00:21 EST