Thread-safe attribution
Manu
turkeyman at gmail.com
Sun Oct 7 23:02:46 UTC 2018
On Sun, Oct 7, 2018 at 10:00 AM Boris-Barboris via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Sunday, 7 October 2018 at 02:01:17 UTC, Manu wrote:
> > ... but I'm really struggling
> > to express it in terms of the type system...
>
> I'm pretty sure no simple attribute system is any more useful
> than current const\shared idiom. I am yet to see a language with
> semantics that actually help with concurrency issues
> (serializability, lock domains, lock ordering, deadlock
> prevention\detection, consistency, write scew and hundreds of
> other problems already known in the domain) on mutable state. SQL
> didn't solve it, I still always have to grab pen and paper and
> brute-force simulate concurrent access to my data in order to
> have any degree of prior knowledge about safety, and
> unfortunately this problem does not look like an easy one to
> crack for language designers.
>
> This is why I mainly ignore shared as a feature completely unless
> I'm forced to. A simple indication (type system attribute) of the
> fact that data is shared is useless for my recent projects just
> adds unneeded casts and lines of code without solving any
> problems.
In our ecosystem within the structure of our scheduling, we would
absolutely get loads of use out of shared if it was unable to access
non-shared members.
That's a major step forward in usefulness compared to now, where you
can just read/write to members arbitrarily, which is just plain wrong,
and not useful in any way.
If shared inhibited access to non-shared members, thereby requiring
you interface the instance only via shared attributed methods (or the
traditional acquire-lock-and-cast-shared-away method), then it would
be infinitely more useful than it is now.
If anyone wanted to make an experimental patch with that rule, I could
test-drive and see how it goes.
Point is, shared is totally useless. Making it useful, even if it's
not 100% solving threading issues, is a better place to be, and opens
up doors for some new designs, and get more experience.
More information about the Digitalmars-d
mailing list