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