Something needs to happen with shared, and soon.

[Sean Kelly]

On Nov 12, 2012, at 2:57 AM, Johannes Pfau <nospam at example.com> wrote:

> Am Sun, 11 Nov 2012 18:30:17 -0800
> schrieb Walter Bright <newshound2 at digitalmars.com>:
> 
>> 
>> To make a shared type work in an algorithm, you have to:
>> 
>> 1. ensure single threaded access by aquiring a mutex
>> 2. cast away shared
>> 3. operate on the data
>> 4. cast back to shared
>> 5. release the mutex
>> 
>> Also, all op= need to be disabled for shared types.
> 
> But there are also shared member functions and they're kind of annoying
> right now:
> 
> * You can't call shared methods from non-shared methods or vice versa.
>  This leads to code duplication, you basically have to implement
>  everything twice:
> 
> ----------
> struct ABC
> {
>        Mutext mutex;
> 	void a()
> 	{
> 		aImpl();
> 	}
> 	shared void a()
> 	{
> 		synchronized(mutex)
> 		    aImpl();  //not allowed
> 	}
> 	private void aImpl()
> 	{
> 		
> 	}
> }
> ----------
> The only way to avoid this is casting away shared in the shared a
> method, but that really is annoying.

Yes.  You end up having two methods for each function, one as a synchronized wrapper that casts away shared and another that does the actual work.


> and then there's also the druntime issue: core.sync doesn't work with
> shared which leads to this schizophrenic situation:
> struct A
> {
>    Mutex m;
>    void a() //Doesn't compile with shared
>    {
>        m.lock();  //Compiles, but locks on a TLS mutex!
>        m.unlock();
>    }
> }

Most of the reason for this was that I didn't like the old implications of shared, which was that shared methods would at some time in the future end up with memory barriers all over the place.  That's been dropped, but I'm still not a fan of the wrapper method for each function.  It makes for a crappy class design.