Beginner stuff...

Andrei mentioned that there have been many months of mulling over models and
options.  Is there a description of what has been figured out so far and
what's left
to do?  Is there a place where I can get caught up on the vision so far?

Topics I know about so far:
- Sean Kelley is working on a message passing system
- Immutable / pure logic should make concurrent code faster, safer, better
- Globals default to TLS unless shared is used.

For people joining this group it would be good to have a sort of bullet
point list of
what questions have been answered and what still has to be worked out.

What are the big unanswered questions?

Thanks,
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100104/43afc7c5/attachment.htm>

An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100104/ad6620b0/attachment-0001.htm>

The most significant bits are:

* D's concurrency approach flagship is a message passing architecture similar to Erlang's. The message passing design must work across (a) threads within the same address space; (b) processes within the same machine; (c) machines within the same subnet; (d) arbitrary remote machines. Depending on cases (a)-(d) there are different strategies of passing data around, e.g. within the same address space immutable data may be shared and shared objects may be aliased. To some extent, however, user code should be able to send a message to a concurrent entity without knowing or caring where the entity is, and what transport method is used. We don't yet have a detailed design for this.

* By default there is no data sharing across threads.

* The shared qualifier allows explicit sharing. The compiler guarantees statically that all mutable shared data is actually marked as shared. __gshared will remain a low-level mechanism to cheat on that guarantee, and we hope to be able to remove that in the future.

* One issue is how shared interacts with synchronized. I'll email about this in a different message.

* One issue is initializing shared and non-shared (TLS) globals. We will have "static this()" be invoked for every thread and define the new module constructor "static shared this()" that is only invoked upon the start of the process.


Andrei

Graham St Jack wrote:
> I'm also in need of a catch-up briefing.
> 
> Thanks,
> Graham
> 
> Kevin Bealer wrote:
>> Beginner stuff...
>>
>> Andrei mentioned that there have been many months of mulling over
>> models and
>> options.  Is there a description of what has been figured out so far
>> and what's left
>> to do?  Is there a place where I can get caught up on the vision so far?
>>
>> Topics I know about so far:
>> - Sean Kelley is working on a message passing system
>> - Immutable / pure logic should make concurrent code faster, safer, better
>> - Globals default to TLS unless shared is used.
>>
>> For people joining this group it would be good to have a sort of
>> bullet point list of
>> what questions have been answered and what still has to be worked out.
>>
>> What are the big unanswered questions?
>>
>> Thanks,
>> Kevin
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> dmd-concurrency mailing list
>> dmd-concurrency at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency

On Jan 4, 2010, at 6:27 AM, Andrei Alexandrescu wrote:

> The most significant bits are:
> 
> * D's concurrency approach flagship is a message passing architecture similar to Erlang's. The message passing design must work across (a) threads within the same address space; (b) processes within the same machine; (c) machines within the same subnet; (d) arbitrary remote machines. Depending on cases (a)-(d) there are different strategies of passing data around, e.g. within the same address space immutable data may be shared and shared objects may be aliased. To some extent, however, user code should be able to send a message to a concurrent entity without knowing or caring where the entity is, and what transport method is used. We don't yet have a detailed design for this.

I think it's fair to assume that an initial implementation will begin with just internal message passing, then a TCP/IP method will be added for everything out of process, and additional methods will be added for performance or other reasons later on.  So long as the API is designed with transport flexibility in mind I think we'll be okay, though it would help to know whether any future possibilities only accept specific data types rather than a pre-encoded blob (MPI perhaps?).