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 54A1DBB91 for ; Sat, 15 Jan 2005 18:53:52 +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 j0FHrpnN014839 for ; Sat, 15 Jan 2005 18:53:52 +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 SAA12016 for ; Sat, 15 Jan 2005 18:53:51 +0100 (MET) Received: from alex.barettalocal.com (host52-68.pool80116.interbusiness.it [80.116.68.52]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j0FHrotw014833 for ; Sat, 15 Jan 2005 18:53:51 +0100 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by alex.barettalocal.com (Postfix) with ESMTP id 4F7812BB7CA; Sat, 15 Jan 2005 18:53:56 +0100 (CET) Message-ID: <41E958B4.3000708@barettadeit.com> Date: Sat, 15 Jan 2005 18:53:56 +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: Luca Pascali Cc: caml-list@inria.fr Subject: Re: [Caml-list] Mutex and posix References: <41E501B4.4060601@yahoo.it> <20050112155607.GB8652@yquem.inria.fr> <41E55E70.2080309@barettadeit.com> In-Reply-To: <41E55E70.2080309@barettadeit.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 41E958B0.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41E958AF.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 wrote:01 posix:01 threads:01 api:01 threads:01 polling:01 mutexes:01 mutexes:01 ocaml:01 polling:01 api: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: Luca Pascali wrote: > Xavier Leroy wrote: > >> [...] >> The latter is a recent addition to the POSIX threads API -- it's not >> in the original POSIX threads spec (POSIX 1003.1c-1995). I wouldn't >> rely on this function being available in all POSIX threads >> implementations. >> >> >> > I didn't know this. > >>> Polling continously is different. If I have two threads that are >>> running with scantimes one multiple of the other, it is possible that >>> one of the two threads (the slower one) fails always or almost always >>> the try_lock command. >>> >> >> >> It's hard to give useful suggestions without knowing more about your >> application, but it could be the case that you're using mutexes to do >> things they are not really designed for, i.e. plain mutual exclusion, >> for which neither trylock nor timedlock are needed. >> >> Maybe your application needs a more complex but better suited >> synchronization mechanism, which can generally be built on top of >> mutexes and conditions, or (at a higher semantic level) Concurrent >> ML-style events. >> >> - Xavier Leroy >> >> >> > I haven't an application. > I was just thinking about how I could port some programs organizations > into Ocaml. > > The case that rised my question was: > If I have a shared resource (let's say a pipe or a queue, or a generic > file descriptor) for performing, for example, asyncronous communication > between threads, it's quite dangerous in terms of deadlocks to perform > myself a polling or locking one thread indefinetly until the resource is > freed. > Polling with try_lock can bring to a deadlock or to a long freezing if > one thread locks the mutex periodically, let's say, every 100 ms for 10 > ms and the other one looks for the same mutex periodically about every > 1200 ms. The probabilty to fall into the locking period is incredibly high. The fact that a program is deadlock free does not depend on the synchronization API but only on the algorithm. If the program deadlocks, the program is faulty. You can actually build correctness proofs in concurrent computation models to make really sure that your algorithm works fine. Never rely on OS timing unless you are modeling a time dependent system. 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