[erlang-questions] Semaphores

[Danesh Daroui]

Corrado Santoro wrote:
> ok wrote:
>   
>> This is debatable.
>> Semaphores are a rather dangerous and low level construction,
>> and Erlang is not really supposed to be a dangerous and low level  
>> language.
>>     
> Indeed the programming model of Erlang is strongly based on message 
> passing, which can be an *alternative method* to semaphores for 
> programming concurrent systems (see the Tanenbaum's book "Modern 
> Operating Systems").
>
>
>   
>> But for most purposes, Erlang *doesn't* share data.
>>     
> Maybe someone reminds that, at the last EUC, the talk by Enzo Nicosia on 
> programming robots with Erlang presented the possibility (or necessity) 
> to have a *native support* for sharing simple data among processes. This 
> was due to avoid the latency of message passing between processes that 
> need/share the same information (this latency is dangerous for a 
> real-time system).
>
> I would let you know that, in the software that we are writing for our 
> next robot (see http://eurobot.diit.unict.it), we are trying to overcome 
> latency problems without adding any data sharing support: the key point 
> is to improve process dynamics and performances by rewriting a 'clone' 
> of some OTP behaviours (gen_fsm and gen_server). The code of our 
> behaviours is small and fast, it does dot feature *all the same* 
> characteristics of gen_fsm/gen_server but only what we strict need for 
> our robots. And till now it's working good!
>
> We will let you know the results ;-)
>
> --Corrado
>
>   
Its cool. I am interested to find out more about your solution. It seems 
that you have solved the problem using State Machines, but if you use a 
server to pass messages through it, it might be the reason that message 
passing is not fast enough as you expect. However, you said that the 
problem is solved, but defining a channel which is accessible by all 
processes to send their request (asynchronous or synchronous doesn't 
matter but synchronous needs its own simulation in Erlang) to one or 
more than one processes which handle requests. Each sender can also have 
its private channel to get the result. Anyway, I thought sending 
messages between processes (not in a distributes architecture) is fast 
enough to avoid such problems. Your task must be very critical. ;)