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 2FD92BB91 for ; Wed, 12 Jan 2005 11:53:42 +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 j0CArfBU013596 for ; Wed, 12 Jan 2005 11:53:41 +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 LAA14828 for ; Wed, 12 Jan 2005 11:53:41 +0100 (MET) Received: from smtp003.mail.ukl.yahoo.com (smtp003.mail.ukl.yahoo.com [217.12.11.34]) by nez-perce.inria.fr (8.13.0/8.13.0) with SMTP id j0CArfZQ007285 for ; Wed, 12 Jan 2005 11:53:41 +0100 Received: from unknown (HELO ?10.0.0.115?) (pasckosky@213.255.109.130 with plain) by smtp003.mail.ukl.yahoo.com with SMTP; 12 Jan 2005 10:53:40 -0000 Message-ID: <41E501B4.4060601@yahoo.it> Date: Wed, 12 Jan 2005 11:53:40 +0100 From: Luca Pascali 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: en MIME-Version: 1.0 To: caml-list@inria.fr Subject: Mutex and posix Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 41E501B5.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41E501B5.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; posix:01 posix:01 mutexes:01 const:01 struct:01 polling:01 threads:01 threads:01 baretta:01 baretta:01 slower:01 functions:01 functions:01 int:01 int:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.5 required=5.0 tests=FROM_ENDS_IN_NUMS 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) 1) for waiting indefinetly for a mutex, 2) failing immediatly if a mutex is locked, 3) wait for a specified amount of time and failing if mutex is still locked when time is expired Module Mutex, provides an interface only to the first two functions: lock and try_lock. My question is: is there any reason for this situation? 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. Luca -- ********************************************************************* Luca Pascali luca@barettadeit.com asxcaml-guru@barettadeit.com http://www.barettadeit.com/ Baretta DE&IT A division of Baretta SRL tel. 02 370 111 55 fax. 02 370 111 54 Our technology: http://www.asxcaml.org/ http://www.freerp.org/