[dmd-concurrency] Smoke test
Michel Fortin
michel.fortin at michelf.com
Thu Jan 7 20:00:47 PST 2010
Le 2010-01-07 à 20:28, Walter Bright a écrit :
> Having a per-thread gc is an optimization, not a fundamental feature of the concurrency model. For one thing, it precludes casting data to immutable. For another, it may result in excessive memory consumption as one thread may have a lot of unused data in its pool that is not available for allocation by another thread.
Both the "per-thread GC + shared GC" model and "the shared GC for everyone" model can be seen as optimizations. The first optimizes for speed, the second optimize for memory usage.
Depending on what you do, it might even make sense to have some threads using the shared GC for everything and other having a thread-local GC to improve speed.
If you want the language to be limited to models where the memory can always be shared between all threads, then that that's fine. It's your prerogative. I'm not so sure it's wise to limit shared semantics to this scenario just to avoid having the shared-immutable combo, but if you're sure that's what you want then I'll stick to it.
I'm glad you're part of this discussion Walter, because defining the concurrency model starts by delimiting precisely its goals and constrains, and it's important to have those stabilize those early if the rest is to make any sense.
Now, perhaps we need to revise this discussion Andrei, Sean, and me had earlier (in the "What is shared?" thread):
Sean Kelly wrote:
> Michel Fortin wrote:
>> Andrei Alexandrescu wrote:
>>
>>> Conversely, an object _not_ marked as "shared" is definitely visible only within one thread.
>>
>> Except for those marked immutable, which also implies shared.
>
> Not necessarily. Immutable means that synchronization isn't necessary for data accessed by multiple threads, but it says nothing about visibility.
Looks like I was right.
--
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/
More information about the dmd-concurrency
mailing list