synchronized class SyncTable(KEY, VAL) {
	private VAL[KEY] table;
	auto require(KEY key) {
		return table.require(key);
	}
}

auto table = new shared SyncTable!(string, string);
table.require("abc");

Fails to compile:

// Error: none of the overloads of template `object.require` are callable using argument types `!()(shared(string[string]), string)`

Tried casting away shared as a workaround but I assume that will cause some kind of TLS catastrophe.

On Friday, 2 September 2022 at 19:15:45 UTC, cc wrote:

synchronized class SyncTable(KEY, VAL) {
	private VAL[KEY] table;
	auto require(KEY key) {
		return table.require(key);
	}
}

auto table = new shared SyncTable!(string, string);
table.require("abc");

// Error: none of the overloads of template `object.require` are callable using argument types `!()(shared(string[string]), string)`

In current version of D language synchronized and shared are independent. In particular shared should be used only for basic types like integers for which atomic operations are well defined, and not for classes.

Anyway if you must send a reference of a synchronized class to a different thread then it's safe to cast shared and then remove it later:

synchronized class A{
...
}

void sendTo(Tid to, A a){
  to.send(cast(shared A) a);
}

A receiveA(){
  A a;
  receive( (shared A sa) { a = cast(A) sa; });
  return a;
}

Unfortunately there isn't any traits that tells you if a class is synchronized or not, so you can't do a safe template function for this.

On Saturday, 3 September 2022 at 09:49:54 UTC, Loara wrote:

Not exactly, a synchronized class member function becomes automatically a shared one.

On 9/2/22 3:15 PM, cc wrote:

I think it will be fine, but you may have an issue. You are returning a non-shared VAL, but your class is shared, which means table, and all the VAL and KEY inside must also be shared.

If you cast away shared you have to put it back upon return.

TLS should not be involved here at all, so there is no problem there.

-Steve

On Saturday, 3 September 2022 at 14:37:16 UTC, Steven Schveighoffer wrote:

Alright, so this is safe then?

alias VAL[KEY] T;
auto require(KEY key) {
	auto unsharedT = cast(T) table;
	auto r = unsharedT.require(key);
	table = cast(shared) unsharedT;
	return cast(shared) r;
}

Was a bit surprised to see mutating unsharedT left table unchanged and needed reassigning.

On 9/4/22 11:24 PM, cc wrote:

alias VAL[KEY] T;
auto require(KEY key) {
     auto unsharedT = cast(T) table;
     auto r = unsharedT.require(key);
     table = cast(shared) unsharedT;
     return cast(shared) r;
}

I think that is fine-ish. You still don't have a shared KEY there. But it really depends on what KEY is. Most likely it's fine (e.g. if KEY is string). If you don't ever really fetch anything out of the key, and just use it to map to your values, I think it should be fine.

Yes, because before an AA contains an element, it is a null AA. When you add the first element, it's allocated. When you make a copy of a null AA, it doesn't affect the original.

You can fix this by reinterpret casting the AA instead of copying it:

auto r = .require(*(cast(T*)&table), key);
// I think this might also work:
auto r = (cast()table).require(key);

-Steve

On Saturday, 3 September 2022 at 14:07:58 UTC, frame wrote:

This is not present in official documentation so other compilers different from dmd aren't forced to assume it. This should be consider an experimental feature of D that users should be able to turn off if they want.

On Tuesday, 6 September 2022 at 10:28:53 UTC, Loara wrote:

Hmm.. LDC does the same to me.

I think the whole synchronization class is an experimental feature :D