[erlang-questions] Semaphores

[Danesh Daroui]

First thanks for your feedback. :)


ok wrote:
> On 15 Mar 2007, at 3:17 pm, Danesh Daroui wrote:
>   
>> I have seen (even posts in this mailing list) that there is a need  
>> to have Semaphores
>> in Erlang
>>     
>
> 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.
>   

Well, it depends on. Sometimes semaphores can be a simple a good 
solution if they are used with care. But of course message passing is 
more advanced and general than semaphores.

>   
>> and since Erlang offers concurrency, Semaphores can be useful in  
>> data sharing.
>>     
>
> But for most purposes, Erlang *doesn't* share data.
>   

Sorry, I explained bad in my previous email. Semaphores can be used 
*not* only for sharing data but for other tasks, mainly synchronization. 
In my sample file you can find a sample for barrier synchronization 
using semaphores.

>   
>> I would be glad to have your feedbacks.
>>     
>
> feedback is a mass noun.
> Source files should be kept to a maximum width of 80 columns;
> the RETURN key is there for a reason and should be used often.
> Source code should be indented using your text editor's indentation
> features, NOT one tab per tab stop.  8-column indentations (what you
> get when you use the tab key) are eye-jarring.
>
> Just like the RETURN key, the space bar is there on your keyboard for
> a reason.  It should be used between "words"; see the Ada Quality &  
> Style
> Guidelines for some nearly excellent advice about this.  Infix operators
> like -> are usually best treated as words, punctuation marks are usually
> best treated like punctuation marks in English.
>
> Unlike Smalltalk, which originated the practice because the Smalltalk  
> character
> set didn't *have* any suitable character like "_", Erlang *does* have  
> "_" and
> *does* allow it in multi_word_identifiers.  (As, for that matter,  
> does modern
> Smalltalk.)  BaStudlyCapsIsNotVeryEasyToRead.
>
>   

It seems that my style in code writing is very irritating. ;) I think 
you are right because my monitors have a high resolution so characters 
are shown very small and therefore lines are too long. I have had same 
problem before, so sorry about that. I also found the link for "Ada 
Quality & Style". I will read it as soon as I can. Thanks again.


> Your new function would be better as
>
>      new(Initial_Count) when is_integer(Initial_Count), Initial_Count  
>  >= 0 ->
> 	spawn(fun () -> semaphore_loop(Initial_Count) end).
>
> There are a number of really basic problems with semaphores.
>
> For one thing, unless you speak Dutch, 'p' and 'v' have no intrinsic  
> meaning
> to you.  (If I say that I think 'p' means 'passieren', that just  
> shows you that
> my ignorance of Dutch is unbounded.)  Even 'increment' and  
> 'decrement' would be
> better names (whichever way around they go), or 'acquire'/'release'.
>   

Frankly, the terms "p" and "v" are very famous, however it can be a 
little confusing because as you mentioned they are Dutch acronyms but 
semaphores are known by them now. So I think it is ok to still use them. 
But I agree, as you said "acquire" and "release" are more clear as Java 
used.


> One big problem is that it is too easy to forget to increment the  
> counter again.
> Smalltalk handles this with 'aSemaphore critical: aBlock'; the Erlang  
> equivalent
> would be
> 	critical(Semaphore, Fun) ->
> 	    p(Semaphore),
> 	    Answer = Fun().
> 	    v(Semaphore),
> 	    Answer.
>   

Yes you are right. Missing a "v" causes deadlock and missing a "p" 
causes livelock. Better alternative to avoid such problems in Monitor. 
So, they simply should be used with care. The solution I suggest is that 
Semaphores should not be used as a main solution to solve problems in 
concurrency. Better solutions like Message Passing and Monitors should 
be considered first and then in some places that seems to be easier and 
more efficient, Semaphores can be used.


> BUT with extra stuff in there to catch exceptions, release the  
> semaphore, and
> re-raise the exceptions.  Eeek.
>
> Oh heck, I leave you to the abundant literature on semaphores to find  
> out why
> semaphores have a bad name.
>
> There really isn't much point in writing
>
> 	case (SemValue>0) of
> 	    true -> ~a~
> 	    false -> ~b~
> 	end
>
> First, the parentheses are worse than useless here.
> Second, you really need spaces around the > because it is hard to see  
> without them.
> Third, what's wrong with
>
> 	if Count > 0 ->
> 	    ~a~
> 	 ; Count <= 0 ->
> 	    ~b~
> 	end
>
>   

I will consider that. Actually I used to remove extra spaces, but I 
think it is just readable to me and not others. :)

> making it completely obvious when each case applies?
>
> Above all, all you really want to do is this:
>
> 	semaphore_loop(Count) ->
> 	    receive
> 	        {acquire,Pid} when Count > 0 ->
> 		    Pid!granted,
> 		    semaphore_loop(Count - 1)
> 	      ; release ->
> 	            semaphore_loop(Count + 1)
> 	      ; stop ->
> 	            ok
> 	    end.
>
>
> 	new(Initial_Count) when is_integer(Count), Count >= 0 ->
> 	    spawn(fun () -> semaphore_loop(Initial_Count) end).
>
>          acquire(Semaphore) ->
> 	    Semaphore!{acquire,self()}.
>
> 	release(Semaphore) ->
> 	    Semaphore!release.
>
> 	stop(Semaphore) ->
> 	    Semaphore!stop.
>
> The next problem is to ensure that a semaphore can only be released  
> by a process
> which had previously acquired it.
>
> Oh yes, lists:append([PID], WaitList)
> can be written more clearly as
> 	[PID] ++ WaitList
> and more clearly still as
> 	[PID | WaitList].
>
>
>   
It was a great tip. I was looking for a shortcut to add an element to 
the list (like Haskell does) but I didn't find. But it is great your 
wrote. Thanks again.

> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
>