Walter is right about transitive readonly - here's the alternative

[Janice Caron]

On 9/13/07, Bill Baxter <dnewsgroup at billbaxter.com> wrote:
> why not just use the word 'synchronized' instead of 'shared'?

Mainly because synchronized is already used. For the record,
synchronized T x;

does compile. However, since it is completely equivalent to

 synchrnonized
 {
     T x;
 }

it is completely useless for variable declaration!

A second reason is that it's too damn long. "sync" would be nicer.

A third reason is that it's spelt the American way. I spell it
"synchronised". (That's not a real argument against, I guess, but it
is annoying).

Anyway, I don't get to choose - Walter would have that privelege. I
can only suggest.




> Your readable/writeable wrappers do indeed sound a lot like RAII mutexes
> I've seen in C++ threading libs.

That's almost exactly what they are.


> But to me, more mutexes doesn't really seem like the answer to our
> multi-threading problems, since as you point out, it's still really
> trivial to get deadlocks and such.

Yeah, but hang on. There is /no/ perfect solution. It is /impossible/
to eliminate deadlocks at compile-time.

Multithreading is hard. There's no way round it. But at least we can
make it easy to have everything properly mutex-locked to that nothing
tramples on memory it shouldn't.



> It seems like this is just and
> expansion on sugary muxtes rather than something that makes
> multithreaded programming fundamentally less error-prone.

It's both. It encapsulates a read/write mutex with the thing being
protected, and it employs RAII to ensure mutex unlocking. So, yes, you
could say it's "just" mutexes.

But I would certainly argue that it makes multithreaded programming
less error-prone. (Not sure what "fundamentally" means in this
context). I certainly do use constructs like this in my own code in
C++, and because of that, I can be confident that I'm thread-safe.


> It also seems like you could nearly get the same functionality out of
> some kind of smart pointer.
> Shared!(T) x; -- a T but no direct access to T or its members is allowed
> Readable!(Shared!(T))(x),
> Writeable!(Shared!(T))(x) -- RAII types, allowing access to x and its
> members

Almost. In fact, they're Shared!(T), Readable!(T) and Writeable!(T).
At least, that's how I implemented them in C++.

Only... with nicer syntax.


> If it isn't possible to make such a smart pointer in D right now (and it
> isn't) that's what should be fixed.  Then this proposal could be
> implemented as a library.

No it couldn't. Not in D. Would you care to guess why not?

*Because const is transitive*

There is no way you could put a read/write mutex (which itself needs
to be mutable) into a const structure unless it's done at a language
level, because Walter won't let you.


> I just don't see this as a viable replacement for 'const' or 'pure'.

That's good, because it isn't.


> Though, maybe your purpose is more to provide something that satisfies
> Walter's threading requirements, leaving const free to be a more C++-ish
> thing.

No, const would still be a D-ish thing. If it were a C-ish thing, it
wouldn't be transitive.