Getting concurrency

[Thomas Lindgren]

--- "Vlad Dumitrescu XX (LN/EAB)"
<vlad.xx.dumitrescu@REDACTED> wrote:

> Hi,
> 
> > From: Thomas Lindgren
> > On the other hand, can we then claim that message
> > passing without shared state is The Answer? As
> most
> > experienced Erlang programmers know, ets and
> mnesia
> > tend to show up after a while, so at the logical
> level
> > shared state is still with us. 
> 
> I apologize if it will show up that I was
> misunderstanding, but I feel a little confused by
> the above.
> 
> I don't think there is any non-trivial concurrent
> setting where data won't be shared at the 'logical
> level' you mention (if I understood correctly what
> you mean by that). Either the data is completely
> intenal to a process, or it is accessible from other
> processes. In the first case there's no concurrency,
> in the other it becomes shared at the logical level.

Yeah, I'm not completely happy with how I expressed
that. But basically I'm thinking of the data _not_
communicated via regular message passing :-) I.e.,
where you start sliding into the difficult
threads-and-locks issues again. 

Well, that part was kind of half-baked, take it for
what it's worth.

> The issue is how to manage access to that data:
> should the clients bear the burden of ensuring that
> the result will be correct, or should there be a
> central manager for that data, independent of the
> clients? 
> 	The former can be very efficient, but above a
> certain level of complexity it is very difficult to
> admninstrate.
> 	The latter is much easier to get right, at the
> price of extra overhead.

Yes, good point. Mnesia on one node could conceivably
be just a single gen_server; much simpler to write,
but likely a bottleneck. I'm not sure there is a good,
systematic way to get from "the simple case" to "the
efficient case", though.

For threads-and-locks, one could start with a big lock
and successively refine it, e.g., split the critical
region into smaller ones and try to shrink them, etc.
Doing this might not yield an optimal solution, but it
would at least optimize execution a bit. 

Is there a useful equivalent to this for message
passing?

OK, back to work ... :-)

Best,
Thomas




		
__________________________________ 
Discover Yahoo! 
Get on-the-go sports scores, stock quotes, news and more. Check it out! 
http://discover.yahoo.com/mobile.html