> So how about a quick summary to figure out where we are?  From memory, I think it's pretty well established that:
>
> 1. shared denotes visibility.  A global shared variable is visible from all threads, an unlabeled variable is thread-local.
> 2. Attaching the shared property to a class instance affects method visibility.  shared and synchronized methods are visible, unlabeled ones are not.
> 3. Attaching the shared property to a value makes that value effectively atomic.  All access and mutation is accomplished via library calls.
>
> I think there was some concern about the shared property of a class instance automatically extending to all of its fields.  Were there other concerns as well?  I know that Jason had mentioned issues with non-statically verifiable shared semantics in general, but that's another ball of wax entirely.
> _______________________________________________
> 
I am assuming that item 2 includes the idea of unlabelled methods being callable from methods of the shared instance.

I think there's a terminological conflation wrt "visibility". Sean, are you talking about thread visibility or about access control?

Andrei

Graham St Jack wrote:
> 
>> So how about a quick summary to figure out where we are?  From memory, I think it's pretty well established that:
>>
>> 1. shared denotes visibility.  A global shared variable is visible
>> from all threads, an unlabeled variable is thread-local.
>> 2. Attaching the shared property to a class instance affects method
>> visibility.  shared and synchronized methods are visible, unlabeled
>> ones are not.
>> 3. Attaching the shared property to a value makes that value
>> effectively atomic.  All access and mutation is accomplished via
>> library calls.
>>
>> I think there was some concern about the shared property of a class
>> instance automatically extending to all of its fields.  Were there
>> other concerns as well?  I know that Jason had mentioned issues with
>> non-statically verifiable shared semantics in general, but that's
>> another ball of wax entirely.
>> _______________________________________________
>> 
> I am assuming that item 2 includes the idea of unlabelled methods being
> callable from methods of the shared instance.
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency

Oops, both.  Thread visibility in 1 and access control in 2.

Sent from my iPhone

On Jan 6, 2010, at 8:02 PM, Andrei Alexandrescu <andrei at erdani.com> wrote:

> I think there's a terminological conflation wrt "visibility". Sean, are you talking about thread visibility or about access control?
>
> Andrei
>
> Graham St Jack wrote:
>>> So how about a quick summary to figure out where we are?  From memory, I think it's pretty well established that:
>>>
>>> 1. shared denotes visibility.  A global shared variable is visible
>>> from all threads, an unlabeled variable is thread-local.
>>> 2. Attaching the shared property to a class instance affects
>>> method visibility.  shared and synchronized methods are visible,
>>> unlabeled ones are not.
>>> 3. Attaching the shared property to a value makes that value
>>> effectively atomic.  All access and mutation is accomplished via
>>> library calls.
>>>
>>> I think there was some concern about the shared property of a class instance automatically extending to all of its fields.  Were there other concerns as well?  I know that Jason had mentioned issues with non-statically verifiable shared semantics in general, but that's another ball of wax entirely. _______________________________________________
>>>
>> I am assuming that item 2 includes the idea of unlabelled methods
>> being callable from methods of the shared instance.
>> _______________________________________________
>> 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 Wed, Jan 6, 2010 at 3:09 PM, Sean Kelly <kelly.sean at apple.com> wrote:

> On Jan 6, 2010, at 11:52 AM, Sean Kelly wrote:
> >
> > In cases 1 and 2, all we really need to worry about is the assignment to
> x.  On recent x86 we should be able to use 8 byte CAS to do it in one shot, but on other architectures the algorithm seems more complicated.  I'd need to poke around to see if there's a published algorithm for updating two values together, but here's a shot at it that uses a special value assigned to the array pointer as a sentinel
>
> I just thought of a better approach.  Simply set the '1' bit of the pointer
> to indicate that an update is taking place, since it really will never be
> set under normal circumstances.
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
>

But be sure to tell the GC that pointers can now look like (ptr % 4 == 1) as
well as (ptr % 4 == 0).  Otherwise a conservative GC might toss your object.

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100107/6a681a26/attachment.htm>

Le 2010-01-06 ? 14:52, Sean Kelly a ?crit :

> class MyClass {
>    void fnA() synchronized {}
>    void fnB() shared {}
> }
> 
> auto x = new MyClass;
> auto y = &x.fnA;
> auto z = &x.fnB;
> 
> I'd guess that the type of y is "delegate() synchronized" and the type of z is "delegate() shared"? Assuming this is right, then it seems like the mutex would be locked when y is called, and the appropriate thing would happen when z is called as well.

It doesn't make much sense to have a different type for delegates to shared function. Shared is the type of the "this" pointer, which is nicely opaquely stored in the delegate itself, propagating shared for the "this" pointer as part of the delegate (or const, or immutable) doesn't serve any purpose.

I'd be tempted to say the same about synchronized, but if the call site is responsible for locking the mutex it might be needed.


> That leaves arrays, which are a tad more complicated because they have both a length and a pointer field.

It's no different for a delegate which has a function pointer and a context pointer.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

The real address in already loaded to a temp var, so mo worries there.

Sent from my iPhone

On Jan 6, 2010, at 11:28 PM, Kevin Bealer <kevinbealer at gmail.com> wrote:

> On Wed, Jan 6, 2010 at 3:09 PM, Sean Kelly <kelly.sean at apple.com>
> wrote:
> On Jan 6, 2010, at 11:52 AM, Sean Kelly wrote:
> >
> > In cases 1 and 2, all we really need to worry about is the
> assignment to x.  On recent x86 we should be able to use 8 byte CAS to do it in one shot, but on other architectures the algorithm seems more complicated.  I'd need to poke around to see if there's a published algorithm for updating two values together, but here's a shot at it that uses a special value assigned to the array pointer as a sentinel
>
> I just thought of a better approach.  Simply set the '1' bit of the
> pointer to indicate that an update is taking place, since it really
> will never be set under normal circumstances.
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
>
> But be sure to tell the GC that pointers can now look like (ptr % 4 == 1) as well as (ptr % 4 == 0).  Otherwise a conservative GC might toss your object.
>
> Kevin
>
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100107/03fec7bb/attachment.htm>

I suppose you're right.  The lock would be acquired inside the function, so no need to make that a part of the delegate type.  As for changing shared delegates, you're right that it's the same as simple assignment for an array.  Oh well.

Sent from my iPhone

On Jan 7, 2010, at 4:12 AM, Michel Fortin <michel.fortin at michelf.com> wrote:

> Le 2010-01-06 ? 14:52, Sean Kelly a ?crit :
>
>> class MyClass {
>>   void fnA() synchronized {}
>>   void fnB() shared {}
>> }
>>
>> auto x = new MyClass;
>> auto y = &x.fnA;
>> auto z = &x.fnB;
>>
>> I'd guess that the type of y is "delegate() synchronized" and the type of z is "delegate() shared"? Assuming this is right, then it seems like the mutex would be locked when y is called, and the appropriate thing would happen when z is called as well.
>
> It doesn't make much sense to have a different type for delegates to shared function. Shared is the type of the "this" pointer, which is nicely opaquely stored in the delegate itself, propagating shared for the "this" pointer as part of the delegate (or const, or immutable) doesn't serve any purpose.
>
> I'd be tempted to say the same about synchronized, but if the call site is responsible for locking the mutex it might be needed.
>
>
>> That leaves arrays, which are a tad more complicated because they have both a length and a pointer field.
>
> It's no different for a delegate which has a function pointer and a context pointer.
>
>
> -- 
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/
>
>
>
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency

I attach a fresh draft. This is qualitatively different from all others because it includes description of code that doesn't exist yet, so it's a great opportunity for those of you who'd want to help.

To avoid "version fatigue" I suggest those of you who've looked over past drafts and sent me comments to skip to the new material. Don't verify whether I incorporated your feedback yet; for now I'm moving forward, but I will make a pass later to make changes prompted by your comments (thanks).

Let me kindly ask you again to contribute by carefully looking over the material and ferreting out the inevitable mistakes, small and large. This is the perfect time to contribute by making sure D won't have some warts we need to put with from now on.


Thanks,

Andrei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.pdf
Type: application/pdf
Size: 133120 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100111/5c251d9e/attachment-0001.pdf>

I remembered there are issues with attachments, so I made draft 3 available from:

http://erdani.com/d/fragment.preview.pdf


Thanks,

Andrei

Le 2010-01-11 ? 5:20, Andrei Alexandrescu a ?crit :

> I attach a fresh draft. This is qualitatively different from all others because it includes description of code that doesn't exist yet, so it's a great opportunity for those of you who'd want to help.

[...]

> Let me kindly ask you again to contribute by carefully looking over the material and ferreting out the inevitable mistakes, small and large. This is the perfect time to contribute by making sure D won't have some warts we need to put with from now on.

About unique... how far can it get without compiler support? It's pretty easy with primitive types, but when it comes to structs and classes, is there a way to enforce that they won't take take their own address (or the address of a member) and leak it elsewhere, in the constructor, in another member function, or even from an external function?

Or will unique work only with primitive types?

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/