Version française
Home     About     Download     Resources     Contact us    
Browse thread
Mutex and posix
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Alex Baretta <alex@b...>
Subject: Re: [Caml-list] Mutex and posix
Brian Hurt wrote:
> On Sat, 15 Jan 2005, Alex Baretta wrote:
> 
> 
>>Luca Pascali wrote:
>>
>>>Just a little question, my curiosity about the thread module.
>>>
>>>I found in Posix (this is from 'info libc' page on section Mutexes) 
>>>these three functions
>>>
>>>Function: int pthread_mutex_lock (pthread_mutex_t *mutex))
>>>Function: int pthread_mutex_trylock (pthread_mutex_t *MUTEX)
>>>Function: int pthread_mutex_timedlock (pthread_mutex_t *MUTEX, const 
>>>struct timespec *ABSTIME)
>>
>>You can probably simulate the third one fairly well by resorting to 
>>Unix.select as a timer, but why in the world would you want to lock for 
>>a while and then forget about it?
> 
> 
> No, you misunderstand what the function does.  The function won't wait 
> more than ABSTIME to acquire the lock.  _mutex_lock() waits forever to get 
> the lock, _mutex_trylock doesn't wait at all, and _mutex_timedlock only 
> waits so long to get the lock.
> 
> Brian

I am aware of this. But, if one really needs the timed primitive, one 
can always simulate it by sampling the mutex state repeatedly with 
_trylock. Unix.select serves the purpose of controlling the sampling time.

Notwithstanding this, when the need arises for a timed primitive in a 
concurrent algorithm, my suggestion is always to attempt to remodel the 
problem rather than the API.

Alex

-- 
*********************************************************************
http://www.barettadeit.com/
Baretta DE&IT
A division of Baretta SRL

tel. +39 02 370 111 55
fax. +39 02 370 111 54

Our technology:

The Application System/Xcaml (AS/Xcaml)
<http://www.asxcaml.org/>

The FreerP Project
<http://www.freerp.org/>