From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 28553BC8C for ; Wed, 19 Jan 2005 04:30:06 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j0J3U5h6031376 for ; Wed, 19 Jan 2005 04:30:05 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id EAA28799 for ; Wed, 19 Jan 2005 04:30:05 +0100 (MET) Received: from herd.plethora.net (herd.plethora.net [205.166.146.1]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j0J3U2nH031349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 19 Jan 2005 04:30:04 +0100 Received: from bhurt.plethora.net (bhurt.plethora.net [205.166.146.49]) by herd.plethora.net (8.13.1/8.13.1) with ESMTP id j0J3TmtT010085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2005 21:29:55 -0600 (CST) Date: Tue, 18 Jan 2005 21:31:56 -0600 (CST) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: Alex Baretta Cc: Ocaml , Luca Pascali Subject: Re: [Caml-list] Mutex and posix In-Reply-To: <41EB7CC4.30204@barettadeit.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at concorde with ID 41EDD43D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41EDD43A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 posix:01 baretta:01 wrote:01 waits:01 waits:01 simulate:01 arises:01 api:01 unix:01 algorithm:01 primitive:02 primitive:02 concurrent:02 suggestion:03 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: On Mon, 17 Jan 2005, Alex Baretta wrote: > > > > 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. Um, no. What happens if the mutex is unlocked for some period of time between your polls, but relocked before you poll the lock again? It's very easy to hit livelock conditions doing this. Brian