www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - shared - no read/write access

reply Manu <turkeyman gmail.com> writes:
Last time we talked about shared, I think we all agreed on one thing;
shared should hot have read/write access to data members.

Does anyone know how to implement this? I would really like to try
some important experiments with shared if it worked.
Mar 19
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2019-03-19 21:08, Manu wrote:
 Last time we talked about shared, I think we all agreed on one thing;
 shared should hot have read/write access to data members.
Not exactly sure of what you're looking for but write access is already disable [1].
 Does anyone know how to implement this? I would really like to try
 some important experiments with shared if it worked.
If it's only the read access that is left to disable I recommend looking at how the write access is disable and try to do the same for read. I suggest to do a project wide search for the error message for write operations, seems pretty unique. Then go from there. [1] https://run.dlang.io/is/ZJ5maE -- /Jacob Carlborg
Mar 19
next sibling parent Rubn <where is.this> writes:
On Tuesday, 19 March 2019 at 20:16:03 UTC, Jacob Carlborg wrote:
 On 2019-03-19 21:08, Manu wrote:
 Last time we talked about shared, I think we all agreed on one 
 thing;
 shared should hot have read/write access to data members.
Not exactly sure of what you're looking for but write access is already disable [1].
 Does anyone know how to implement this? I would really like to 
 try
 some important experiments with shared if it worked.
If it's only the read access that is left to disable I recommend looking at how the write access is disable and try to do the same for read. I suggest to do a project wide search for the error message for write operations, seems pretty unique. Then go from there. [1] https://run.dlang.io/is/ZJ5maE
Only read-write-modify are disabled, you can still write as long as you don't read from it at the same time. shared int global; shared class Foo { int a; } void main() { auto foo = new shared Foo; foo.a = 1; }
Mar 19
prev sibling next sibling parent Rubn <where is.this> writes:
On Tuesday, 19 March 2019 at 20:16:03 UTC, Jacob Carlborg wrote:
 On 2019-03-19 21:08, Manu wrote:
 Last time we talked about shared, I think we all agreed on one 
 thing;
 shared should hot have read/write access to data members.
Not exactly sure of what you're looking for but write access is already disable [1].
 Does anyone know how to implement this? I would really like to 
 try
 some important experiments with shared if it worked.
If it's only the read access that is left to disable I recommend looking at how the write access is disable and try to do the same for read. I suggest to do a project wide search for the error message for write operations, seems pretty unique. Then go from there. [1] https://run.dlang.io/is/ZJ5maE
A more obvious example of it being misused: shared int global; shared class Foo { int a; } void main() { auto foo = new shared Foo; foo.a = foo.a + 1; }
Mar 19
prev sibling parent Manu <turkeyman gmail.com> writes:
On Tue, Mar 19, 2019 at 1:20 PM Jacob Carlborg via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 2019-03-19 21:08, Manu wrote:
 Last time we talked about shared, I think we all agreed on one thing;
 shared should hot have read/write access to data members.
Not exactly sure of what you're looking for but write access is already disable [1].
 Does anyone know how to implement this? I would really like to try
 some important experiments with shared if it worked.
If it's only the read access that is left to disable I recommend looking at how the write access is disable and try to do the same for read. I suggest to do a project wide search for the error message for write operations, seems pretty unique. Then go from there. [1] https://run.dlang.io/is/ZJ5maE -- /Jacob Carlborg
Erm, change `++` to `= 10`. Read/write from a shared thing should be a compile error in every circumstance.
Mar 19
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 19 March 2019 at 20:08:37 UTC, Manu wrote:
 Last time we talked about shared, I think we all agreed on one 
 thing; shared should hot have read/write access to data members.

 Does anyone know how to implement this? I would really like to 
 try some important experiments with shared if it worked.
This looks like a good place to start: https://github.com/dlang/dmd/commit/7535f3dc86e9e88c4ee609dd98b5305224c3b88a
Mar 19
prev sibling parent reply Kagamin <spam here.lot> writes:
On Tuesday, 19 March 2019 at 20:08:37 UTC, Manu wrote:
 Last time we talked about shared, I think we all agreed on one 
 thing; shared should hot have read/write access to data members.

 Does anyone know how to implement this? I would really like to 
 try some important experiments with shared if it worked.
shared qualifier provides a guarantee that thread local data is thread local, it doesn't provide safety for concurrency, not supposed to, because it's not realistically feasible at such low level, and attempts to do it like yours only add noise, complicate reasoning and make errors only more likely. Normally it's unshared data that should have a qualifier, because that's actually a feature being provided, but because it would be a nuisance, the opposite was done.
Mar 19
next sibling parent Manu <turkeyman gmail.com> writes:
On Tue, Mar 19, 2019 at 2:25 PM Kagamin via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Tuesday, 19 March 2019 at 20:08:37 UTC, Manu wrote:
 Last time we talked about shared, I think we all agreed on one
 thing; shared should hot have read/write access to data members.

 Does anyone know how to implement this? I would really like to
 try some important experiments with shared if it worked.
shared qualifier provides a guarantee that thread local data is thread local, it doesn't provide safety for concurrency, not supposed to, because it's not realistically feasible at such low level, and attempts to do it like yours only add noise, complicate reasoning and make errors only more likely. Normally it's unshared data that should have a qualifier, because that's actually a feature being provided, but because it would be a nuisance, the opposite was done.
I have literally no idea what you're talking about.
Mar 19
prev sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Tuesday, 19 March 2019 at 21:20:58 UTC, Kagamin wrote:
 On Tuesday, 19 March 2019 at 20:08:37 UTC, Manu wrote:
 Last time we talked about shared, I think we all agreed on one 
 thing; shared should hot have read/write access to data 
 members.

 Does anyone know how to implement this? I would really like to 
 try some important experiments with shared if it worked.
shared qualifier provides a guarantee that thread local data is thread local, it doesn't provide safety for concurrency, not supposed to, because it's not realistically feasible at such low level, and attempts to do it like yours only add noise, complicate reasoning and make errors only more likely. Normally it's unshared data that should have a qualifier, because that's actually a feature being provided, but because it would be a nuisance, the opposite was done.
In it's current form the `shared` qualifier is not improving the thread-safety of D code. Manus proposal does improve thread-safety. I am strongly in favor for considering it seriously. Being conservative and disallowing all access is by far the most sensible handling if safety is a concern.
Mar 20
next sibling parent reply Kagamin <spam here.lot> writes:
On Wednesday, 20 March 2019 at 13:25:01 UTC, Stefan Koch wrote:
 In it's current form the `shared` qualifier is not improving 
 the thread-safety
 of D code.
It does, proof: https://issues.dlang.org/show_bug.cgi?id=6585
 Being conservative and disallowing all access is by far the 
 most sensible handling
 if safety is a concern.
Added noise and cognitive load on programmer causes more bugs, not more safety. shared is already restrictive enough to handle, making it more restrictive will only make people give up on it more often.
Mar 20
parent reply Manu <turkeyman gmail.com> writes:
On Wed, Mar 20, 2019 at 11:20 AM Kagamin via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Wednesday, 20 March 2019 at 13:25:01 UTC, Stefan Koch wrote:
 In it's current form the `shared` qualifier is not improving
 the thread-safety
 of D code.
It does, proof: https://issues.dlang.org/show_bug.cgi?id=6585
That is most certainly not a bug, that's absolutely 100% correct behaviour. It's absolutely not okay to pass a pointer to shared data to memcpy! It needs some external synchronisation, and then cast shared away when you know you have a thread-local lock on it.
 Being conservative and disallowing all access is by far the
 most sensible handling
 if safety is a concern.
Added noise and cognitive load on programmer causes more bugs, not more safety. shared is already restrictive enough to handle, making it more restrictive will only make people give up on it more often.
So, just to be clear, you favour shared being broken and meaningless to actually meaning something and being useful? I don't have the energy to repeat the last uber-thread on the issue; you'll find the full discussion in the forum history.
Mar 20
parent reply Kagamin <spam here.lot> writes:
On Wednesday, 20 March 2019 at 20:15:23 UTC, Manu wrote:
 So, just to be clear, you favour shared being broken and 
 meaningless
 to actually meaning something and being useful?
Its meaning is to provide guarantee that thread-local data doesn't have threading issues and I posted the proof of its usefulness.
Mar 21
next sibling parent reply Rubn <where is.this> writes:
On Thursday, 21 March 2019 at 19:03:23 UTC, Kagamin wrote:
 On Wednesday, 20 March 2019 at 20:15:23 UTC, Manu wrote:
 So, just to be clear, you favour shared being broken and 
 meaningless
 to actually meaning something and being useful?
Its meaning is to provide guarantee that thread-local data doesn't have threading issues and I posted the proof of its usefulness.
If the data is thread local, then it is already guaranteed to have no conflict with other threads. Hence it being "thread local", only the local thread can access the data. There's no need for a "shared" qualifier in this regard.
Mar 21
parent reply Kagamin <spam here.lot> writes:
On Thursday, 21 March 2019 at 19:50:31 UTC, Rubn wrote:
 If the data is thread local, then it is already guaranteed to 
 have no conflict with other threads. Hence it being "thread 
 local", only the local thread can access the data. There's no 
 need for a "shared" qualifier in this regard.
In case of D the claim doesn't hang in a vacuum, but is supported by the type system.
Mar 25
parent reply Rubn <where is.this> writes:
On Monday, 25 March 2019 at 08:36:42 UTC, Kagamin wrote:
 On Thursday, 21 March 2019 at 19:50:31 UTC, Rubn wrote:
 If the data is thread local, then it is already guaranteed to 
 have no conflict with other threads. Hence it being "thread 
 local", only the local thread can access the data. There's no 
 need for a "shared" qualifier in this regard.
In case of D the claim doesn't hang in a vacuum, but is supported by the type system.
You don't use the type system with thread local data. Using shared, actually creates global data, not thread local data. I'll ask this now since it seems you are talking mostly gibberish. Do you even know what thread local data is ?
Mar 25
parent reply Kagamin <spam here.lot> writes:
On Monday, 25 March 2019 at 21:04:37 UTC, Rubn wrote:
 You don't use the type system with thread local data. Using 
 shared, actually creates global data, not thread local data.
Unqualified types are specified to be thread local, so thread local data is definitely expressed in the type system.
Mar 26
parent reply Rubn <where is.this> writes:
On Tuesday, 26 March 2019 at 08:35:42 UTC, Kagamin wrote:
 On Monday, 25 March 2019 at 21:04:37 UTC, Rubn wrote:
 You don't use the type system with thread local data. Using 
 shared, actually creates global data, not thread local data.
Unqualified types are specified to be thread local, so thread local data is definitely expressed in the type system.
__gshared int a; See above, you have an unqualified type. Would you say it is thread local? Is there any way you can see that it is thread local by the type alone? Are there any guarantees that it won't be accessed by another thread? An unqualified type is bare, it does not provide any thread-safety, you can easy pass it around to another thread to be used and cause race conditions. Anyways back to the original question you avoided:
 Its meaning is to provide guarantee that thread-local data 
 doesn't have threading issues and I posted the proof of its 
 usefulness.
Why do you think "shared" means thread-local data? And then you go on to say that it is unqualified types? I shall ask again, do you know what thread-local data is ?
Mar 26
parent reply Kagamin <spam here.lot> writes:
On Tuesday, 26 March 2019 at 21:09:18 UTC, Rubn wrote:
 __gshared int a;

 See above, you have an unqualified type. Would you say it is 
 thread local? Is there any way you can see that it is thread 
 local by the type alone?
It has thread local type. It's an escape provided to ease migration from other languages, when it's difficult for whatever reason to have shared data qualified as shared.
 Its meaning is to provide guarantee that thread-local data 
 doesn't have threading issues and I posted the proof of its 
 usefulness.
Why do you think "shared" means thread-local data? And then you go on to say that it is unqualified types?
shared is a qualifier for data that is not thread local, so that thread local data remains unqualified to reduce churn for it.
Mar 27
parent reply Rubn <where is.this> writes:
On Wednesday, 27 March 2019 at 18:25:09 UTC, Kagamin wrote:
 On Tuesday, 26 March 2019 at 21:09:18 UTC, Rubn wrote:
 __gshared int a;

 See above, you have an unqualified type. Would you say it is 
 thread local? Is there any way you can see that it is thread 
 local by the type alone?
It has thread local type. It's an escape provided to ease migration from other languages, when it's difficult for whatever reason to have shared data qualified as shared.
Is it thread local data? How do you identify it is not thread-local data by type only (it is unqualified)?
 Its meaning is to provide guarantee that thread-local data 
 doesn't have threading issues and I posted the proof of its 
 usefulness.
Why do you think "shared" means thread-local data? And then you go on to say that it is unqualified types?
shared is a qualifier for data that is not thread local, so that thread local data remains unqualified to reduce churn for it.
You have not answered the question.
Mar 27
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, March 27, 2019 2:58:06 PM MDT Rubn via Digitalmars-d wrote:
 On Wednesday, 27 March 2019 at 18:25:09 UTC, Kagamin wrote:
 On Tuesday, 26 March 2019 at 21:09:18 UTC, Rubn wrote:
 __gshared int a;

 See above, you have an unqualified type. Would you say it is
 thread local? Is there any way you can see that it is thread
 local by the type alone?
It has thread local type. It's an escape provided to ease migration from other languages, when it's difficult for whatever reason to have shared data qualified as shared.
Is it thread local data? How do you identify it is not thread-local data by type only (it is unqualified)?
If you use __gshared, it's up to you to ensure that thread-safety is guaranteed - just like you have to guarantee thread-safety when you cast away shared to operate on a shared object (usually after having locked a mutex to protect it). __gshared is really only intended for linking against C globals (which aren't typed as shared, because C doesn't have shared), and its use in any program should be minimal. Regardless, it's up to the programmer to use it correctly, just like it's up to the programmer to ensure that trusted code is actually safe, because as far as the compiler is concerned, __gshared is not part of the type. So, any code using that variable will assume that it's thread-local, leaving it up to the programmer to protect it correctly, whereas with shared, the compiler is supposed to prevent operations that aren't thread-safe (thus usually requiring shared to be cast away to operate on the variable). - Jonathan M Davis
Mar 31
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On Thu, Mar 21, 2019 at 12:05 PM Kagamin via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Wednesday, 20 March 2019 at 20:15:23 UTC, Manu wrote:
 So, just to be clear, you favour shared being broken and
 meaningless
 to actually meaning something and being useful?
Its meaning is to provide guarantee that thread-local data doesn't have threading issues and I posted the proof of its usefulness.
But that's now what `shared` does... it allows (guarantees even) many threads mutate the same data at random with no protections. By inhibiting read/write access, you force the user to obtain a lock (or other synchronisation method) in order to access the shared data. Without that, the path of least resistance is to just access the data, and that's a race 100% of the time, by definition (because it's `shared`).
Mar 21
parent reply Kagamin <spam here.lot> writes:
On Thursday, 21 March 2019 at 20:50:09 UTC, Manu wrote:
 But that's now what `shared` does... it allows (guarantees 
 even) many
 threads mutate the same data at random with no protections.
 By inhibiting read/write access, you force the user to obtain a 
 lock
 (or other synchronisation method) in order to access the shared 
 data.
 Without that, the path of least resistance is to just access 
 the data,
 and that's a race 100% of the time, by definition (because it's
 `shared`).
Some memory accesses are thread safe, then synchronization is not needed.
Mar 25
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Monday, 25 March 2019 at 08:37:42 UTC, Kagamin wrote:
 On Thursday, 21 March 2019 at 20:50:09 UTC, Manu wrote:
 But that's now what `shared` does... it allows (guarantees 
 even) many
 threads mutate the same data at random with no protections.
 By inhibiting read/write access, you force the user to obtain 
 a lock
 (or other synchronisation method) in order to access the 
 shared data.
 Without that, the path of least resistance is to just access 
 the data,
 and that's a race 100% of the time, by definition (because it's
 `shared`).
Some memory accesses are thread safe, then synchronization is not needed.
So what you are saying is that shared can thread-safe; For access where synchronization is not needed. In those cases it technically does not matter if the data is shared or not. Let's talk about the case now where data is actually shared between threads, How can I distinguish in the type-system if I get a pointer which others may, write to at the same time? Cheers, Stefan
Mar 25
parent reply Kagamin <spam here.lot> writes:
On Monday, 25 March 2019 at 10:39:06 UTC, Stefan Koch wrote:
 How can I distinguish in the type-system if I get a pointer 
 which others may, write to at the same time?
Qualified as shared, like anything that's not thread local.
Mar 26
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Tuesday, 26 March 2019 at 08:34:33 UTC, Kagamin wrote:
 On Monday, 25 March 2019 at 10:39:06 UTC, Stefan Koch wrote:
 How can I distinguish in the type-system if I get a pointer 
 which others may, write to at the same time?
Qualified as shared, like anything that's not thread local.
Okay, so a shared variable may change at any time. Is it safe to read or write it then?
Mar 26
parent Kagamin <spam here.lot> writes:
On Tuesday, 26 March 2019 at 10:12:36 UTC, Stefan Koch wrote:
 Okay, so a shared variable may change at any time.
 Is it safe to read or write it then?
If it fits in the chosen multithreading design.
Mar 27
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, March 25, 2019 2:37:42 AM MDT Kagamin via Digitalmars-d wrote:
 On Thursday, 21 March 2019 at 20:50:09 UTC, Manu wrote:
 But that's now what `shared` does... it allows (guarantees
 even) many
 threads mutate the same data at random with no protections.
 By inhibiting read/write access, you force the user to obtain a
 lock
 (or other synchronisation method) in order to access the shared
 data.
 Without that, the path of least resistance is to just access
 the data,
 and that's a race 100% of the time, by definition (because it's
 `shared`).
Some memory accesses are thread safe, then synchronization is not needed.
If the compiler can guarantee thread-safety, then there shouldn't be a problem, and nothing needs to be made illegal, but that's usually not the case. The primary exception would be stuff like atomics, and that's typed with shared, so you can pass shared variables to them. And it's not a problem, because thread-safety is guaranteed. In the cases where synchronization _is_ needed, then those operations should be illegal, requiring the programmer to protect the object appropriately and then cast away shared to operate on it while it's protected. That way, nothing marked as shared is violating thread-safety, and the code where there is a risk of violating thread-safety is system. So, it becomes fairly easy to grep for the portions of the code where you need to worry about threading bugs. And of course, because shared functions can operate on shared objects, it's possible to do stuff like encapsulate a mutex inside an object so that it does all of the necessary synchronization internally, and none of the code using that object needs to do any casting or anything else that's system to use the shared object. - Jonathan M Davis
Mar 31
parent reply Kagamin <spam here.lot> writes:
On Sunday, 31 March 2019 at 07:12:08 UTC, Jonathan M Davis wrote:
 If the compiler can guarantee thread-safety, then there 
 shouldn't be a problem, and nothing needs to be made illegal, 
 but that's usually not the case. The primary exception would be 
 stuff like atomics, and that's typed with shared, so you can 
 pass shared variables to them. And it's not a problem, because 
 thread-safety is guaranteed.
False sense of thread safety already? Code is not magically thread safe because it uses atomics, they are only a tool. Thread safety is a global property and can't be easily provided on low level alone. But added churn can increase mistakes because of increased cognitive load.
 In the cases where synchronization _is_ needed, then those 
 operations should be illegal, requiring the programmer to 
 protect the object appropriately and then cast away shared to 
 operate on it while it's protected. That way, nothing marked as 
 shared is violating thread-safety, and the code where there is 
 a risk of violating thread-safety is  system. So, it becomes 
 fairly easy to grep for the portions of the code where you need 
 to worry about threading bugs.
safe code might be disallowed to access shared data, that's understandable, but like for system, it's difficult to provide protection for shared code that can pull its weight. Also greppability implies that casting away shared is not really inevitable, it's needed if you want to apply algorithm that was written for thread local data, but keeping data and methods as shared will help communicate that it's not an ordinary thing happening here (a use case for private shared methods).
Apr 02
next sibling parent Manu <turkeyman gmail.com> writes:
On Tue, Apr 2, 2019 at 4:40 AM Kagamin via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Sunday, 31 March 2019 at 07:12:08 UTC, Jonathan M Davis wrote:
 If the compiler can guarantee thread-safety, then there
 shouldn't be a problem, and nothing needs to be made illegal,
 but that's usually not the case. The primary exception would be
 stuff like atomics, and that's typed with shared, so you can
 pass shared variables to them. And it's not a problem, because
 thread-safety is guaranteed.
False sense of thread safety already? Code is not magically thread safe because it uses atomics, they are only a tool. Thread safety is a global property and can't be easily provided on low level alone. But added churn can increase mistakes because of increased cognitive load.
 In the cases where synchronization _is_ needed, then those
 operations should be illegal, requiring the programmer to
 protect the object appropriately and then cast away shared to
 operate on it while it's protected. That way, nothing marked as
 shared is violating thread-safety, and the code where there is
 a risk of violating thread-safety is  system. So, it becomes
 fairly easy to grep for the portions of the code where you need
 to worry about threading bugs.
safe code might be disallowed to access shared data, that's understandable, but like for system, it's difficult to provide protection for shared code that can pull its weight. Also greppability implies that casting away shared is not really inevitable, it's needed if you want to apply algorithm that was written for thread local data, but keeping data and methods as shared will help communicate that it's not an ordinary thing happening here (a use case for private shared methods).
I think a lot of people just don't quite visualise what shared means right. I think it's a fact that `shared` data can not be read/written, period... not under any circumstance. If you want to touch it, it's only reasonable to access shared data if you have confidence that you're the only one accessing it at that moment. In that sense, it's a reasonable description to say that you are creating (or asserting) a thread-local context with respect to that data, and we express that by casting away shared. It's on you to assure that the thread-local environment you are assuming is true. The compiler can't help with this. Taking a mutex is one such form of creating that thread-local context; if you lock others off from accessing this data, then it is effectively thread-local to you for that period, so you may cast away shared and access it during that window. This code can never be safe. But it may be tested and trusted. Nothing means anything though if you can read/write to shared data as you can right now. If that's possible, shared has no meaning at all, and no value that I can figure.
Apr 03
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, April 2, 2019 5:37:20 AM MDT Kagamin via Digitalmars-d wrote:
 On Sunday, 31 March 2019 at 07:12:08 UTC, Jonathan M Davis wrote:
 If the compiler can guarantee thread-safety, then there
 shouldn't be a problem, and nothing needs to be made illegal,
 but that's usually not the case. The primary exception would be
 stuff like atomics, and that's typed with shared, so you can
 pass shared variables to them. And it's not a problem, because
 thread-safety is guaranteed.
False sense of thread safety already? Code is not magically thread safe because it uses atomics, they are only a tool. Thread safety is a global property and can't be easily provided on low level alone. But added churn can increase mistakes because of increased cognitive load.
Atomics guarantee that the read/write operations are thread-safe, but no they obviously can't guarantee things like that a set of interrelated variables whose values should be kept in sync are actually protected against multiple threads mucking with them at once. So, maybe a better way to put it is that the compiler won't allow operations that it can't guarantee are atomic (or which are marked shared).
 In the cases where synchronization _is_ needed, then those
 operations should be illegal, requiring the programmer to
 protect the object appropriately and then cast away shared to
 operate on it while it's protected. That way, nothing marked as
 shared is violating thread-safety, and the code where there is
 a risk of violating thread-safety is  system. So, it becomes
 fairly easy to grep for the portions of the code where you need
 to worry about threading bugs.
safe code might be disallowed to access shared data, that's understandable, but like for system, it's difficult to provide protection for shared code that can pull its weight. Also greppability implies that casting away shared is not really inevitable, it's needed if you want to apply algorithm that was written for thread local data, but keeping data and methods as shared will help communicate that it's not an ordinary thing happening here (a use case for private shared methods).
Greppability just means that you can easily find the code in question, and between the keywords shared, cast, trusted, and system, it should be easy to quickly narrow down the code that involves casting away shared and thus find the code that has to be closely examined for threading issues. And code involving atomics is easily greppable - and thus easily findable - for the same reason. And no, it shouldn't be the case that everything using a shared variable has to constantly cast away shared to do anything with it, because those operations can be encapsulated in functions - a prime example of that being an object that has its own mutex to protect its data. Nothing using the object would need to cast away shared, but internally, that's exactly what the object would need to do in order to actually mutate the data. That's already true to an extent, because some read/write operations are illegal on shared objects and have been for some time. The problem is that they aren't all illegal. So, instead of the whole thing being set up so that you clearly have to cast away shared to mutate data, you end up only having to cast it away some of the time, just increasing the annoyance factor. Either we need to go all the way and make all non-atomic read/write operations illegal on shared data or just give up on shared providing any protections at all beyond ensuring that code not involving casts can't make the type system treat shared data as thread-local or vice versa. - Jonathan M Davis
Apr 03
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, March 20, 2019 7:25:01 AM MDT Stefan Koch via Digitalmars-d 
wrote:
 On Tuesday, 19 March 2019 at 21:20:58 UTC, Kagamin wrote:
 On Tuesday, 19 March 2019 at 20:08:37 UTC, Manu wrote:
 Last time we talked about shared, I think we all agreed on one
 thing; shared should hot have read/write access to data
 members.

 Does anyone know how to implement this? I would really like to
 try some important experiments with shared if it worked.
shared qualifier provides a guarantee that thread local data is thread local, it doesn't provide safety for concurrency, not supposed to, because it's not realistically feasible at such low level, and attempts to do it like yours only add noise, complicate reasoning and make errors only more likely. Normally it's unshared data that should have a qualifier, because that's actually a feature being provided, but because it would be a nuisance, the opposite was done.
In it's current form the `shared` qualifier is not improving the thread-safety of D code. Manus proposal does improve thread-safety. I am strongly in favor for considering it seriously. Being conservative and disallowing all access is by far the most sensible handling if safety is a concern.
shared already prevents some operations that the compiler can't guarantee are thread-safe (e.g. IIRC, ++i on built-in types is disallowed). The problem is that it doesn't prevent all of them, and it can't work properly unless it does, because otherwise it can't make any guarantees about thread-safety, which is one of the main reasons that shared exists. As with safe, the protections on shared have been added piecemeal over time rather than getting it all figured out up front like ideally would have happened. - Jonathan M Davis
Mar 31