Fully transitive const is not necessary
Sean Kelly
sean at invisibleduck.org
Thu Apr 3 16:54:59 PDT 2008
== Quote from Sean Reque (seanthenewt at yahoo.com)'s article
> Steven Schveighoffer Wrote:
> > "Sean Kelly" wrote
> > > == Quote from Janice Caron article
> > >> ...which raises an interesting point. Can "synchronized" be used on a
> > >> const object? What about an invariant object?
> > >
> > > They'll work just fine with const objects in D. Object monitors in D
> > > currently
> > > live outside the const checking scheme.
> >
> > Oh so you mean Walter couldn't implement mutexes without logical const huh?
> > I think this part of the system should be ripped out and you should have to
> > pass mutexes along with objects everywhere you want to ensure thread safety
> > and const is transitive. That's easier and less obfuscated, right?
> >
> > -Steve
> >
> >
> The whole point of invariant objects and pure functions in terms of thread safety is that you don't
need any form of synchronized data access. If, for instance a piece of data is guaranteed not to change,
then two cores can hold two separate copies of the same data in each of their local caches instead of
having to fetch the same data from an external source. Requiring synchronization on all const objects
would entirely defeat optimizations like these.
As I've illustrated previously, invariance doesn't eliminate the need for synchronization.
It's true that if two threads have existing reference to a shared piece of invariant data
then further accesses of that data do not need to be synchronized, but unless the data
exists in ROM or was created at application start time there must be a synchronization
point involved when each new thread obtains a reference to this data. If this were not
the case, lock-free programming would be largely unnecessary or at least painfully
simple. The problem with shared-memory multiprogramming is the fact that memory
is shared. Functional languages are good for multiprogramming because they don't
have any shared data, not because their data is all invariant (though I believe the latter
should help for additional automatic parallelization of loops and such even though
that's not commonly done today AFAIK).
Sean
More information about the Digitalmars-d
mailing list