Multy-core CPUs, ERLANG
Sebastian Sastre
ssastre at seaswork.com
Tue Oct 23 20:13:06 UTC 2007
I don't have access to it but maybe someone has this paper?:
http://portal.acm.org/citation.cfm?id=38844&coll=portal&dl=ACM
I wonder if there is some light there
cheers,
Sebastian Sastre
> -----Mensaje original-----
> De: squeak-dev-bounces at lists.squeakfoundation.org
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] En
> nombre de Peter William Lount
> Enviado el: Martes, 23 de Octubre de 2007 12:09
> Para: The general-purpose Squeak developers list
> Asunto: Re: Multy-core CPUs, ERLANG
>
> Hi,
>
> Continued.
>
> Of course one could also implement a copy-on-write-bit for
> objects in the
> "read-only-shared-top-level-object-space-of-the-image". In
> order to accomplish any work a process must be forked! Also,
> this way any process that forks off will need to copy all of
> the objects it modifies into it's own private object-space
> until the process commits it's changes into the top level
> object-space or until it aborts. That's assuming a Software
> Transactional Memory scheme is added to Smalltalk.
>
> Actually this idea is quite appealing if done right.
>
> Of course there are a host of other awesomely complex
> problems implied by the above that a simple concurrency model
> will NOT solve.
>
> Concurrency isn't like automatic garbage collection - which
> is actually quite broad and complex a field - at all. The
> sets of problems with concurrent systems are way more
> complex. This is especially the case when you bring
> distribution beyond a single compute node into the fold and
> especially when other issues such as distributed garbage
> collection are required. Welcome to the complex world of
> tomorrow today.
>
> What do the actual vendor's staff who write the virtual
> machines think about this?
>
> All the best,
>
> Peter William Lount
>
More information about the Squeak-dev
mailing list
|