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 25EC6BB91 for ; Wed, 12 Jan 2005 16:56:08 +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 j0CFu7F9022621 for ; Wed, 12 Jan 2005 16:56:07 +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 QAA26654 for ; Wed, 12 Jan 2005 16:56:07 +0100 (MET) Received: from yquem.inria.fr (yquem.inria.fr [128.93.8.37]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j0CFu7Ms022618; Wed, 12 Jan 2005 16:56:07 +0100 Received: by yquem.inria.fr (Postfix, from userid 18180) id 1AF74BB91; Wed, 12 Jan 2005 16:56:07 +0100 (CET) Date: Wed, 12 Jan 2005 16:56:07 +0100 From: Xavier Leroy To: Luca Pascali Cc: caml-list@inria.fr Subject: Re: [Caml-list] Mutex and posix Message-ID: <20050112155607.GB8652@yquem.inria.fr> References: <41E501B4.4060601@yahoo.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41E501B4.4060601@yahoo.it> User-Agent: Mutt/1.3.28i X-Miltered: at concorde with ID 41E54897.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41E54897.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 posix:01 posix:01 mutexes:01 const:01 struct:01 threads:01 api:01 threads:01 polling:01 mutexes:01 slower:01 functions:01 suited:01 int:01 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: > 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) 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. > 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