election details *PLEASE READ*
Andreas Raab
andreas.raab at gmx.de
Fri Feb 23 06:21:42 UTC 2007
Nice summary. The only thing I have to add is that your approach (3) is
how Croquet works. We currently don't do it inside a single image but we
have been talking about it and at some point we will get around to it.
Cheers,
- Andreas
J J wrote:
>> From: karl <karl.ramberg at comhem.se>
>> Reply-To: The general-purpose Squeak developers
>> list<squeak-dev at lists.squeakfoundation.org>
>> To: The general-purpose Squeak developers
>> list<squeak-dev at lists.squeakfoundation.org>
>> Subject: Re: election details *PLEASE READ*
>> Date: Thu, 22 Feb 2007 22:44:07 +0100
>>
>>> I think we should try to take things from other languages that make
>>> sense for smalltalk, but I don't think there will be a time when one
>>> language (even smalltalk!) will be perfect for every task. We will
>>> still need at least Haskell. :)
>> Another issue that will come up in the near future is multi core
>> processors. What must be done with Squeak to utilize all the
>> processors and what are the benefits and drawback of the different
>> approaches ? What can the board do to help in this effort ?
>
> Afaik there are 3 ways of handling true concurrent execution (i.e. not
> green threads):
>
> 1) Fine-grained locking/shared thread state:
>
> The old way of running heavy weight threads, sharing memory across
> threads and using some kind of locking to protect against race conditions.
>
> Positive: Hrm, well I guess there is the most support for this, since
> it is probably the most common. If you don't use any locking but only
> read the data shared this is very fast approach.
>
> Negative: It simply doesn't scale well. It also doesn't compose well.
> You can't simply put two independently created pieces of code together
> that use locking and expect it to work. Stated another way,
> fine-grained locking is the manual memory management of concurrency
> methodologies [1]. If any part of your code is doing fine-grain
> locking, you can never "just use it" somewhere else. You have to dig
> deep down in every method to make sure you aren't going to cause a
> deadlock.
>
> This one would probably be very hard to add to Squeak based on what John
> said.
>
> 2) Shared state, transactional memory:
>
> Think relational database. You stick a series of code in an "atomic"
> block and the system does what it has to to make it appear as the memory
> changes occurred atomically.
>
> Positive: This approach affords some composability. You still should
> know if the methods your calling are going to operate on memory, but in
> the case that you put two pieces of code together that you know will,
> you can just slap an atomic block around them and it works. The system
> can also ensure that nested atomic blocks work as expected to further
> aid composability. This approach can often require very few changes to
> existing code to make it thread safe. And finally, you can still have
> all (most?) of the benefits of thread-shared memory without having to
> give up so much abstraction (i.e. work at such a low level).
>
> Negative: To continue the above analogy, I consider this one the
> "reference counted memory management" of options. That is, it works as
> expected, but can end up taking more resources and time in the end. My
> concern with this approach is that it still does need some knowledge of
> what the code you are calling does at a lower level. And most people
> aren't going to want to worry about it so they will just stick "atomic"
> everywhere. That probably wont hurt anything, but it forces the system
> to keep track of a lot more things then it should, and this bookkeeping
> is not free.
>
> This one would also require some VM (probably very big) changes to
> support and could be tough to get right.
>
> 3) Share nothing message passing:
>
> Basically, no threads, only independent processes that send messages
> between each other to get work done.
>
> Positive: This approach also allows a high level of composability. If
> you get new requirements, you typically add new processes to deal with
> them. And at last, you don't have to think about what the other "guy"
> is going to do. A system designed in this manner is very scalable; in
> Erlang for example, a message send doesn't have to worry if it is
> sending to a local process or a totally different computer. A message
> send is a message send. There is no locking at all in this system, so
> no process is sleeping waiting for some other process to get finished
> with a resource it wants (low level concerns). Instead a process will
> block waiting for another process to give him work (high level concerns).
>
> Negative: This requires a new way of architecting in the places that
> use it. What we are used to is; call a function and wait for an
> answer. An approach like this works best if your message senders never
> care about answers. The "main loop" sends out work, the consumers
> consume it and generate output that they send to other consumers (i.e.
> not the main loop). In some cases, what we would normally do in a
> method is done in a whole other process. Code that uses this in
> smalltalk will also have to take care, as we *do* have state that could
> leak to local processes. We would either have to make a big change how
> #fork and co. work today to ensure no information can be shared, or we
> would have to take care in our coding that we don't make changes to data
> that might be shared.
>
> I think this one would be, by far, the easiest to add to Squeak (unless
> we have to change #fork and co, of course). I think the same code that
> writes out objects to a file could be used to serialize them over the
> network. The system/package/whatever can check the recipient of a
> message send to decide if it is a local call that doesn't need to be
> serialized or not.
>
> [1] The big win usually cited for GC's is something to the effect of
> "well, people forget to clean up after themselves and this frees up
> their time by not making them". But really, the big win was
> composability. In any GC-less system, it is always a nightmare of who
> has responsibility for deleting what, when. You can't just use a new
> vendor API, you have to know if it cleans up after itself, do I have to
> do it, is there some API I call? With a GC you just forget about it,
> use the API and everything works.
>
> _________________________________________________________________
> Win a Zune™—make MSN® your homepage for your chance to win!
> http://homepage.msn.com/zune?icid=hmetagline
>
>
>
More information about the Squeak-dev
mailing list
|