English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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: 2005-01-17 (08:52)
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.


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)

The FreerP Project