Browse thread
Mutex and posix
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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. 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/>