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 01AC5BB91 for ; Mon, 17 Jan 2005 09:52:24 +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 j0H8qNYa013183 for ; Mon, 17 Jan 2005 09:52:23 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA23812 for ; Mon, 17 Jan 2005 09:52:23 +0100 (MET) Received: from alex.barettalocal.com (h213-255-109-130.albacom.net [213.255.109.130] (may be forged)) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j0H8qMhP003961 for ; Mon, 17 Jan 2005 09:52:22 +0100 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by alex.barettalocal.com (Postfix) with ESMTP id 9B6402BB7CA; Mon, 17 Jan 2005 09:52:21 +0100 (CET) Message-ID: <41EB7CC4.30204@barettadeit.com> Date: Mon, 17 Jan 2005 09:52:20 +0100 From: Alex Baretta User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: Brian Hurt , Ocaml , Luca Pascali Subject: Re: [Caml-list] Mutex and posix References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 41EB7CC7.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41EB7CC6.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; baretta:01 caml-list:01 posix:01 wrote:01 baretta:01 wrote:01 posix:01 mutexes:01 const:01 struct:01 simulate:01 waits:01 waits:01 simulate:01 arises:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.0 X-Spam-Level: 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) The FreerP Project