[dmd-concurrency] synchronized, shared, and regular methods inside the same class

[Sean Kelly]

On Jan 6, 2010, at 7:35 AM, Andrei Alexandrescu wrote:

> Michel Fortin wrote:
>> Ok, so I understand that you meant "atomic { int y = x; y++; x = y;
>> }" to be some kind of transaction, where the whole becomes atomic.
>> I'd be very happy to see transactional memory in D. I have experience
>> with database transactions, but I'm not sure how familiar I am with
>> the topic of software transactional memory.
>> Anyway, let's talk about it.
> 
> Transactional memory is simplifying a great deal of multithreaded programming, and there's little to not like about it. However, as far as I know we don't have any STM expert on board who's also willing to implement it for D, which is overriding the debate on whether STM will be a prevailing mechanism of doing threaded work. So as of the time being we don't plan to add STM capabilities to D.
> 
> If one or some on this list are willing to provide a soup-to-nuts design and implementation of STM for D in a matter of weeks, please speak up. Otherwise or until then, I encourage the interested people to discuss it off-list. Thanks.

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.