On Mon, Jul 7, 2008 at 4:32 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> Peter William Lount wrote:
>
>> I think it's best to let each developer-user choose how many native
>> threads per image and how many images are loaded and which images are
>> loaded. After all it's their program. Isn't our job as language and systems
>> designers to provide them with the tools that they need to build the systems
>> that they want to build? I think so. What do you think?
>>
>
> Everything you say, to the letter, can and has been said about manual
> memory management. The point you're apparently not getting is that the "one
> native thread per image" is not only a workaround to avoid some very nasty
> issues down in the VM, it also provides a clean *model* for concurrency. No
> such model exists for shared state concurrency which is the real problem -
> since all synchronization is manual, it is pretty much impossible to write
> large scalable systems correctly with manual locks and mutexes. Just as it
> is impossible to write large scalable systems correctly with manual memory
> management.
>


It's not *that* hard to write a large, scalable, concurrent systems using
Processes and Semaphores. Sure, at times it can be difficult with horrible
bugs that take a decade to manifest, but if you use consistent patterns and
encapsulate complex behaviour well, it is quite tractable.

There are a few nice abstractions one could use. Let me know if you know of
any ones not here: http://gulik.pbwiki.com/Parallel+processing

Gulik.

-- 
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080707/37a4d9f8/attachment.htm