Re: would a mutex_wait be useful?

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Tue Nov 04 2008 at 10:18:29 -0800, Matt Thomas wrote:
> 
> On Nov 4, 2008, at 3:50 AM, Mindaugas Rasiukevicius wrote:
> 
> >Matt Thomas <matt%3am-software.com@localhost> wrote:
> >>
> >>
> >>I'd like to be able to do a mutex_enter(9) which could be  
> >>interruptable.
> >>If interrupted, it would return the error why it was interrupted.
> >
> >Where/when do you need interruptible mutex?
> 
> I was replacing code in arm32/mem.c with a home grown lock with  
> mutex_enter.
> Relatively easy to do except it no longer does PCATCH.

I see only one PCATCH in there, and that's definitely a case for an
interlock (which the current code is lacking) and cv_wait_sig + cv_signal.

> >>Maybe called int mutex_wait(kmutex_t *mtx, int ticks); and if  
> >>ticks == 0
> >>becomes (mutex_tryenter(mtx) ? 0 : ETIMEOUT).  If tick == -1, means
> >>wait forever.
> >>
> >>mutex_wait would use PCATCH for its sleeps and return EINTR if a  
> >>signal
> >>was caught.
> >
> >That does not sound like a good API. If specific synchronisation is  
> >needed,
> >I think wrappers with mutex_tryenter() could be used for that.
> 
> Not easily.  And rolling your own seems wrong.  Hence the proposal  
> for a common
> method to do it.

My reason for opposing adding such interfaces without a very good cause,
as ridiculous as it might sound, is that they reduce the portability
of the kernel sychronization primitives because there is no pthread
equivalent (without some distasteful home cookery a'la microwave).