Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Jan 2005 00:39:05 +0300 (MSK)
From:      Igor Sysoev <is@rambler-co.ru>
To:        David Xu <davidxu@freebsd.org>
Cc:        freebsd-threads@freebsd.org
Subject:   Re: higher speed mutexes
Message-ID:  <20050117001919.B35122@is.park.rambler.ru>
In-Reply-To: <41E318C2.3040304@freebsd.org>
References:  <41DCEA91.6040402@he.iki.fi> <41DCFD2F.2040207@freebsd.org> <41E0256A.1000801@he.iki.fi> <41E318C2.3040304@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050117001919.B35122>