Getting locks and sharing: was RE: Getting concurrency
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
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