From: Alex Baretta <alex@barettadeit.com>
To: Brian Hurt <bhurt@spnz.org>, Ocaml <caml-list@inria.fr>,
Luca Pascali <luca@barettadeit.com>
Subject: Re: [Caml-list] Mutex and posix
Date: Mon, 17 Jan 2005 09:52:20 +0100 [thread overview]
Message-ID: <41EB7CC4.30204@barettadeit.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0501151335400.5563-100000@localhost.localdomain>
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/>
next prev parent reply other threads:[~2005-01-17 8:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-12 10:53 Luca Pascali
2005-01-12 15:56 ` [Caml-list] " Xavier Leroy
2005-01-12 17:29 ` Luca Pascali
2005-01-15 17:53 ` Alex Baretta
2005-01-15 17:49 ` Alex Baretta
2005-01-15 19:37 ` Brian Hurt
2005-01-17 8:52 ` Alex Baretta [this message]
2005-01-19 3:31 ` Brian Hurt
2005-01-19 9:34 ` Alex Baretta
2005-01-17 12:33 ` Luca Pascali
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41EB7CC4.30204@barettadeit.com \
--to=alex@barettadeit.com \
--cc=bhurt@spnz.org \
--cc=caml-list@inria.fr \
--cc=luca@barettadeit.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox