Re: [Caml-list] Mutex and posix

[Alex Baretta <alex@barettadeit.com>]

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)
<http://www.asxcaml.org/>

The FreerP Project
<http://www.freerp.org/>