| Author |
Message |
< Erlang ~ Concurrency Theory, Message Passing Model, Locks, and OOP |
| fikre |
 Posted: Tue Mar 10, 2009 1:19 pm |
 |
|
|
Joined: 07 Nov 2008
Posts: 5
|
I have a few questions regarding concurrency in general and Erlang's programming model.
The first is regarding locks in Erlang.
It seems to me that locks are not needed since we have no shared memory in Erlang.
But what about when we have shared resources such as files? Might we not need to synchronize access to these resources by making use of synchronization abstractions such as monitors and semaphores?
Another concept that confuses me in the non shared memory model is idea of having a process ID for a process that can be 'shared' between other processes. Would this bring about the need to use locks semaphores ... for synchronization purposes when communicating with that single process?
Does it make sense to compare a receive block in a server process to a synchronized method in java?
I'm interested in the answers to these questions as I'm trying to understand when and whether some of common design patterns for concurrency (mainly patterns from the book POSA2) used today in OOP are applicable to problems in Erlang.
From what I have been reading it seems that the synchronization patterns that make use of locks (etc)might not be applicable to the message passing / no shared memory / immutable state programming model, but I'd like to hear what other people have to say.
Is there any work that goes deep into the subject of concurrency models and erlang comparing Erlang's model to OOP paradigm.
If I do get any replies I'm expecting replies encouraging me to stop thinking in terms of objects and the OOP paradigm, but what I'm trying to do is in fact compare these different models in order to find similarities and differences. |
|
|
| Back to top |
 
|
| uwiger |
| Posted: Tue Mar 10, 2009 4:42 pm |
|
|
|
User
Joined: 03 Jul 2006
Posts: 604
Location: Sweden
|
fikre wrote: I have a few questions regarding concurrency in general and Erlang's programming model.
The first is regarding locks in Erlang.
It seems to me that locks are not needed since we have no shared memory in Erlang.
True, low-level locking is not needed in Erlang.
fikre wrote: But what about when we have shared resources such as files? Might we not need to synchronize access to these resources by making use of synchronization abstractions such as monitors and semaphores?
It might be necessary, yes. I'd call this, high-level, or application-level locks. In Erlang, there are different ways to do it. You can serialize access to the resource using a process, or you can use something like Code: global:trans(Id, Fun)
fikre wrote: Another concept that confuses me in the non shared memory model is idea of having a process ID for a process that can be 'shared' between other processes. Would this bring about the need to use locks semaphores ... for synchronization purposes when communicating with that single process?
No, not visibly so. The Erlang virtual machine will take care of any locking required to enable many processes to send to the same receiver. And the 'sharing' of process identifiers is not physical sharing, but rather a copying semantics; each process holds its own copy of the information.
fikre wrote: Does it make sense to compare a receive block in a server process to a synchronized method in java?
No, I think it is a confusing analogy. You could implement a mailbox with the use of synchronized methods in Java, but I don't think it helps to view a message queue as a synchronized shared data structure. Just imagine that messages magically enter the message queue without interfering with each other - it's up to the virtual machine to sort it out, and you really don't have a guarantee that you acquire a lock on the message queue at the moment of sending. In the distributed case, this is definitely not the case.
fikre wrote: From what I have been reading it seems that the synchronization patterns that make use of locks (etc)might not be applicable to the message passing / no shared memory / immutable state programming model, but I'd like to hear what other people have to say.
Yes, you might want to concentrate mainly on distributed algorithms, but one of the most useful patterns by far is the client-server pattern (gen_server in Erlang). It will solve a great many problems. Mnesia and ets will also help a lot, and don't require that much learning, actually.
fikre wrote: Is there any work that goes deep into the subject of concurrency models and erlang comparing Erlang's model to OOP paradigm.
I don't think so. A very good book to read is Communicating Sequential Processes by C.A.R. Hoare. CSP is a little different from Erlang, but it may help you get into the right frame of mind.
fikre wrote: If I do get any replies I'm expecting replies encouraging me to stop thinking in terms of objects and the OOP paradigm, but what I'm trying to do is in fact compare these different models in order to find similarities and differences.
A noble endeavour. That was the first thing I did, when I got into Erlang 17 years ago.  |
|
|
| Back to top |
|
| fikre |
| Posted: Wed Mar 11, 2009 12:37 am |
|
|
|
Joined: 07 Nov 2008
Posts: 5
|
Excellent.
Thanks. Its nice to get some perspective. |
|
|
| Back to top |
|
| Bill M. |
| Posted: Mon Mar 16, 2009 12:38 pm |
|
|
|
User
Joined: 06 Jun 2008
Posts: 24
Location: New York
|
Hi All:
I was reading this thread with some interest, and wanted to dig a bit deeper regarding this part of the response. Most of the original post is omitted for brevity.
uwiger wrote:
fikre wrote: From what I have been reading it seems that the synchronization patterns that make use of locks (etc)might not be applicable to the message passing / no shared memory / immutable state programming model, but I'd like to hear what other people have to say.
Yes, you might want to concentrate mainly on distributed algorithms, but one of the most useful patterns by far is the client-server pattern (gen_server in Erlang). It will solve a great many problems. Mnesia and ets will also help a lot, and don't require that much learning, actually.
fikre wrote: Is there any work that goes deep into the subject of concurrency models and erlang comparing Erlang's model to OOP paradigm.
I don't think so. A very good book to read is Communicating Sequential Processes by C.A.R. Hoare. CSP is a little different from Erlang, but it may help you get into the right frame of mind.
I wonder about how to squeeze the most concurrency out of code using the server model. Consider for example an application using cryptography (and hence the crypto package). The crypto package uses exactly this sort of server model if I understand. If many concurrent threads want to encrypt concurrently, won't the server model of crypto model cause sequential execution? Does Erlang have a natural way to express the sort of parallelism I want so that servers can be more "elastic", i.e. parallelize the execution of requests, and better exploit multi core environments?
Regards:
Bill M. |
|
|
| Back to top |
|
| uwiger |
| Posted: Tue Mar 17, 2009 10:27 am |
|
|
|
User
Joined: 03 Jul 2006
Posts: 604
Location: Sweden
|
Bill M. wrote: I wonder about how to squeeze the most concurrency out of code using the server model.
Well, actually, using the server model normally serves to limit concurrency by serializing a certain class of operations. Since servers in Erlang can be very lightweight, you can decompose your problem into a great many servers.
Bill M. wrote: Consider for example an application using cryptography (and hence the crypto package). The crypto package uses exactly this sort of server model if I understand. If many concurrent threads want to encrypt concurrently, won't the server model of crypto model cause sequential execution?
The crypto driver does seem to have support for per-port locking, so then it would be possible to open several instances of it. I haven't tried this, so there might be issues, but in general, this is a way to achieve greater parallelism.
Bill M. wrote: Does Erlang have a natural way to express the sort of parallelism I want so that servers can be more "elastic", i.e. parallelize the execution of requests, and better exploit multi core environments?
The way to do it in Erlang is to use several worker processes, either spawning a "process pool" that the server controls, or by spawning a process per request. There is no other syntactic construct for doing things in parallel.
/Ulf |
|
|
| Back to top |
|
| wuji |
| Posted: Tue Sep 18, 2012 7:33 am |
|
|
|
User
Joined: 10 Aug 2012
Posts: 654
|
long-dead king of rock 'n roll."You name it, I got got [h4]cheap jordan shoes[/h4] got it," he confessed to ABCNews.com.Cary's multiple televisions and DVDs
Elvis around the clock, and on weekends at city clubs clubs replica designer *beep* clubs and in national gigs, he becomes Elvis."When I'm dressed
like Elvis, I feel like Superman. I'm the king of of cheap jordans for sale of rock 'n roll -- TCB," says Cary, quoting Elvis
acronym for "taking care of business," a phrase the singer singer cheap jordans free shipping singer coined when his life, like Cary's, began its downward
am poor man, but my things make me feel rich."Cary's rich."Cary's [h2]cheap jordan shoes[/h2] rich."Cary's story kicks off the first episode in the fourth
of TLC's "Hoarding: Buried Alive," which airs Sunday, July 8 8 cheap designer *beep* 8 at 9 p.m. The series examines the lives of
whose emotional attachment to objects causes serious health and safety safety [h1]authentic jordans[/h1] safety dangers and threatens their relationships with family and friends."The
Cary doesn't exist anymore," says his friend Joe, who, with with cheap replica *beep* with wife Francesca on the TV show, unsuccessfully tries to
clear a pathway through the bags of food and debris debris cheap authentic jordans debris that eat up every inch of Cary's apartment."There is |
|
|
| Back to top |
|
| dongdongwu |
| Posted: Wed Sep 19, 2012 2:40 am |
|
|
|
User
Joined: 19 Sep 2012
Posts: 236
|
| Girls would refuse to even leave their replicas behind. specifically when the product beats the complete meaning of the Christian Louboutin men outlet; in conditions of good quality and detailing.If Cinderella was residing in your twenty primary century as opposed to the aged a single then there would not be any 'Happy actually after'. properly appears like girls nowadays are as well fond of the strong;Christian Louboutin Men Shoes to leave them in your center of nowhere.Christian Louboutin for men Shoes would arrive true handy being a excellent handbag using the glimpse and really feel belonging to the authentic but at a very much lesser price tag adding as very much as types picture in your process. |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
