higher speed mutexes

[Igor Sysoev]

On Tue, 11 Jan 2005, David Xu wrote:

> Petri Helenius wrote:
>> 
>> What happens if the process holding the lock dies?
>> 
>>> In detail, I don't use thr_suspend and thr_wakeup, I use more reliable 
>>> way:
>>> umtx_wait + umtx_wake, I have added them into kernel sometimes ago.
>>> 
>> I was looking at the umtx routines and wondering if I could use them 
>> instead of pthread API.
>> 
> I will add owner list, when a thread blocked on umtx, an owner list
> will be created for the umtx,  and blocked thread will  lookup the owner
> in system, if there is no the owner, the owner was dead, kernel marks
> the umtx is in broken state, next locker will find the brokeness, and
> still gets the lock successfully but with errno is EPIPE, if a thread exits
> with its owner list not empty, in thr_exit, kernel will mark all umtxes
> to broken state, and wake up a waiter on each umtx, the waiter should
> find the brokeness...., it will let do priority proction and priority inherit
> mutex for POSIX..., I am looking for time to do it....

Is it possible to add the kqueue notification when a busy mutex will be freed ?

Something like

    _umtx_op(umtx, UMTX_OP_EVENT_LOCK, id, kqueue, timeout);

If the mutex is free, UMTX_OP_EVENT_LOCK operate as UMTX_OP_LOCK.

But if the mutex is busy, UMTX_OP_EVENT_LOCK should register the mutex event
to the kqueue and return EBUSY (and so). When the mutex will be freed,
the application will received the EVFILT_UMTX event. However, kernel
should not lock the mutex that was just freed, but it should only notify about
freeing.


Igor Sysoev
http://sysoev.ru/en/