On 10/16/18 2:10 PM, Manu wrote:
On Tue, Oct 16, 2018 at 6:35 AM Steven Schveighoffer via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
On 10/16/18 9:25 AM, Steven Schveighoffer wrote:
On 10/15/18 2:46 PM, Manu wrote:
From there, it opens up another critical opportunity; T* -> shared(T)*
promotion.
Const would be useless without T* -> const(T)* promotion. Shared
suffers a similar problem.
If you write a lock-free queue for instance, and all the methods are
`shared` (ie, threadsafe), then under the current rules, you can't
interact with the object when it's not shared, and that's fairly
useless.
Oh, I didn't see this part. Completely agree with Timon on this, no
implicit conversions should be allowed.
Why?
int x;
shared int *p = &x; // allow implicit conversion, currently error
passToOtherThread(p);
useHeavily(&x);
How is this safe? Thread1 is using x without locking, while the other
thread has to lock. In order for synchronization to work, both sides
have to agree on a synchronization technique and abide by it.
If you want to have a lock-free implementation of something, you can
abstract the assignments and reads behind the proper mechanisms anyway,
and still avoid locking (casting is not locking).
Sorry, I don't understand what you're saying. Can you clarify?
I'd still mark a lock-free implementation shared, and all its methods
shared. shared does not mean you have to lock, just cast away shared. A
lock-free container still has to do some special things to make sure it
avoids races, and having an "unusable" state aids in enforcing this.
-Steve
