election details *PLEASE READ*
J J
azreal1977 at hotmail.com
Fri Feb 23 05:18:29 UTC 2007
Oh, I forgot to mention, Haskell is also experimenting with a system where
the language environment figures out the dependencies between functions and
automatically moves the portions it can into separate threads. I don't
really see this as viable for Smalltalk (and I could of course be wrong in
this), so I didn't include it, but I did intend to mention it. :)
>From: "J J" <azreal1977 at hotmail.com>
>Reply-To: The general-purpose Squeak developers
>list<squeak-dev at lists.squeakfoundation.org>
>To: squeak-dev at lists.squeakfoundation.org
>Subject: Re: election details *PLEASE READ*
>Date: Fri, 23 Feb 2007 05:14:34 +0000
>
>>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 Zunemake MSN® your homepage for your chance to win!
>http://homepage.msn.com/zune?icid=hmetagline
>
>
_________________________________________________________________
Find what you need at prices youll love. Compare products and save at MSN®
Shopping.
http://shopping.msn.com/default/shp/?ptnrid=37,ptnrdata=24102&tcode=T001MSN20A0701
More information about the Squeak-dev
mailing list
|