Getting locks and sharing: was RE: Getting concurrency

Vlad Dumitrescu vlad_dumitrescu@REDACTED
Wed Jun 15 20:33:22 CEST 2005

From: "Vance Shipley" <vances@REDACTED>
> I'm not sure what to do after that.  Do you make the "extra" nodes
> hidden and try and load share behind the scenes or do you just leave
> it at that and expect people to use normal erlang distribution?


My two cents on this, very sketchy.

The most complex way is to make the mulator multi-CPU aware, with all the 
hassle involved. Just the distributed garbage collection could probably 
support a couple of Ph.D. theses. On the plus side, load balancing is 

The simplest way is to just strt several nodes, let them know about each 
other and leave it to the application developers to take advantage of the 
fact. In order for this to be useful, some kind of framework is needed to 
handle the housekeeping, like load balancing and a new global process 
registration. Applications must be multi-CPU aware, in order to use it.

In-between I see another way, that I like most: let the framework be hidden 
behind the regular bifs, making the whole mechanism completely transparent. 
Then all applications could use it. Since it's integrated in the vm, it 
could do things better than an Erlang-only solution.

What I think is needed at the most basic level is:
    - a spawn bif that does load balancing behind the scenes (but looks like 
a local spawn)
    - a way to let the node cluster look as just one node to the outside 
(including the global registration service), but still be able to identify 
each other.

And I think it should be enough to get started... There's plenty of useful 
things to add later.

What do you think?


More information about the erlang-questions mailing list