On Saturday, 20 October 2018 at 16:41:41 UTC, Stanislav Blinov
wrote:
Those are not "ok". They're only "ok" under Manu's proposal so
long as the author of C promises (via documentation) that
that's indeed "ok". There can be no statically-enforced
guarantees that those calls are "ok", or that is
On Sunday, 21 October 2018 at 05:47:14 UTC, Manu wrote:
On Sat, Oct 20, 2018 at 10:10 AM Stanislav Blinov via
Digitalmars-d wrote:
Synchronized with what? You still have `a`, which isn't
`shared` and doesn't require any atomic access or
synchronization. At this point it doesn't matter if it'
On Sunday, 21 October 2018 at 11:25:16 UTC, aliak wrote:
On Saturday, 20 October 2018 at 16:41:41 UTC, Stanislav Blinov
wrote:
Those are not "ok". They're only "ok" under Manu's proposal so
long as the author of C promises (via documentation) that
that's indeed "ok". There can be no statically-
On Sunday, 21 October 2018 at 09:50:09 UTC, Walter Bright wrote:
On 10/20/2018 11:24 AM, Manu wrote:
This is an unfair dismissal.
It has nothing at all to do with fairness. It is about what the
type system guarantees in @safe code. To repeat, the current
type system guarantees in @safe code
On Sunday, 21 October 2018 at 09:58:18 UTC, Walter Bright wrote:
On 10/20/2018 11:08 AM, Nicholas Wilson wrote:
You can if no-one else writes to it, which is the whole point
of Manu's proposal. Perhaps it should be const shared instead
of shared but still.
There is no purpose whatsoever to da
On Sunday, 21 October 2018 at 12:45:43 UTC, Stanislav Blinov
wrote:
On Sunday, 21 October 2018 at 05:47:14 UTC, Manu wrote:
On Sat, Oct 20, 2018 at 10:10 AM Stanislav Blinov via
Digitalmars-d wrote:
Synchronized with what? You still have `a`, which isn't
`shared` and doesn't require any atom
On Sunday, 21 October 2018 at 13:24:49 UTC, Stanislav Blinov
wrote:
On Sunday, 21 October 2018 at 11:25:16 UTC, aliak wrote:
When I say ok, I mean assuming the implementer actually wrote
correct code. This applies to any shared method today as well.
This ("ok") can only be achieved if the "imp
On Sunday, 21 October 2018 at 09:58:18 UTC, Walter Bright wrote:
On 10/20/2018 11:08 AM, Nicholas Wilson wrote:
You can if no-one else writes to it, which is the whole point
of Manu's proposal. Perhaps it should be const shared instead
of shared but still.
There is no purpose whatsoever to da
On Sat, 20 Oct 2018 22:47:14 -0700, Manu wrote:
> Looking at the meat of the program; you open a file, and distribute it
> to do accesses (I presume?)
> Naturally, this is a really weird thing to do, because even if the API
> is threadsafe such that it doesn't crash and reads/writes are
> seria
On Sun., 21 Oct. 2018, 2:55 am Walter Bright via Digitalmars-d,
wrote:
>
> On 10/20/2018 11:24 AM, Manu wrote:
> > This is an unfair dismissal.
>
> It has nothing at all to do with fairness. It is about what the type system
> guarantees in @safe code. To repeat, the current type system guarantees
On Sun, Oct 21, 2018 at 3:00 AM Walter Bright via Digitalmars-d
wrote:
>
> On 10/20/2018 11:08 AM, Nicholas Wilson wrote:
> > You can if no-one else writes to it, which is the whole point of Manu's
> > proposal. Perhaps it should be const shared instead of shared but still.
>
> There is no purpose
I'd like to add that if the compiler can prove that a T* points to a unique T,
then it can be implicitly cast to shared(T)*. And it does so, like the result of
.dup can be so converted.
On 21.10.18 17:54, Nicholas Wilson wrote:
As soon as that is done, you've got a data race with the other
existing unshared aliases.
You're in @trusted code, that is the whole point. The onus is on the
programmer to make that correct, same with regular @safe/@trusted@system
code.
Not all o
On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
wrote:
>
> On 21.10.18 17:54, Nicholas Wilson wrote:
> >
> >> As soon as that is done, you've got a data race with the other
> >> existing unshared aliases.
> >
> > You're in @trusted code, that is the whole point. The onus is on the
>
On Sunday, 21 October 2018 at 09:50:09 UTC, Walter Bright wrote:
Manu's Proposal ---
@safe:
int i;
int* a = &i;
StartNewThread(a); // Compiles! Coder has no idea!
... in the new thread ...
void StartOfNewThread(shared(int)* b) {
... we have two threads accessing 'i',
one thinks it
On Sunday, 21 October 2018 at 18:45:15 UTC, Walter Bright wrote:
I'd like to add that if the compiler can prove that a T* points
to a unique T, then it can be implicitly cast to shared(T)*.
And it does so, like the result of .dup can be so converted.
This can be achieved by using the unique st
On Sun, Oct 21, 2018 at 5:50 AM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Sunday, 21 October 2018 at 05:47:14 UTC, Manu wrote:
>
> >> And yet, if we're lucky, we get
> >> a consistent instacrash. If we're unlucky, we get memory
> >> corruption, or an unsolicited write to another currently o
On Sunday, 21 October 2018 at 19:07:37 UTC, Nicholas Wilson wrote:
On Sunday, 21 October 2018 at 09:50:09 UTC, Walter Bright wrote:
Your proposal makes that impossible because the compiler would
allow unshared data to be implicitly typed as shared.
Yes, but not the other way around.
Whoops t
On Sunday, 21 October 2018 at 19:22:45 UTC, Manu wrote:
On Sun, Oct 21, 2018 at 5:50 AM Stanislav Blinov via
Digitalmars-d wrote:
Because the whole reason to have `shared` is to avoid the
extraneous checks that you mentioned above,
No, it is to assure that you write correct not-broken code.
On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
Yes, but the problem you describe is arises from implicit conversion in the
other direction, which is not part of the proposal.
It's Manu's example.
On 10/21/2018 2:08 PM, Walter Bright wrote:
On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
Yes, but the problem you describe is arises from implicit conversion in the
other direction, which is not part of the proposal.
It's Manu's example.
Then I don't know what the proposal is. Pieces of it
On Sun, 21 Oct 2018 12:04:16 -0700, Manu wrote:
> On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
> wrote:
>> Note that there may well be a good way to get the good properties of MP
>> without breaking the type system, but MP itself is not good because it
>> breaks @safe.
>
> Show m
On Sunday, 21 October 2018 at 21:32:14 UTC, Walter Bright wrote:
On 10/21/2018 2:08 PM, Walter Bright wrote:
On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
Yes, but the problem you describe is arises from implicit
conversion in the other direction, which is not part of the
proposal.
It's Man
On Sunday, 21 October 2018 at 22:12:18 UTC, Neia Neutuladh wrote:
On Sun, 21 Oct 2018 12:04:16 -0700, Manu wrote:
On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
wrote:
Note that there may well be a good way to get the good
properties of MP without breaking the type system, but M
On Sun, Oct 21, 2018 at 11:31 AM Manu wrote:
>
> On Sun., 21 Oct. 2018, 2:55 am Walter Bright via Digitalmars-d,
> wrote:
> >
> > On 10/20/2018 11:24 AM, Manu wrote:
> > > This is an unfair dismissal.
> >
> > It has nothing at all to do with fairness. It is about what the type system
> > guarante
On Sun, Oct 21, 2018 at 2:35 PM Walter Bright via Digitalmars-d
wrote:
>
> On 10/21/2018 2:08 PM, Walter Bright wrote:
> > On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
> >> Yes, but the problem you describe is arises from implicit conversion in the
> >> other direction, which is not part of the
On 21.10.18 20:46, Manu wrote:
Shared data is only useful if, at some point, it is read/written, presumably by
casting it to unshared in @trusted code. As soon as that is done, you've got a
data race with the other existing unshared aliases.
If such a race is possible, then the @trusted function
On Sun, Oct 21, 2018 at 3:15 PM Neia Neutuladh via Digitalmars-d
wrote:
>
> On Sun, 21 Oct 2018 12:04:16 -0700, Manu wrote:
> > On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
> > wrote:
> >> Note that there may well be a good way to get the good properties of MP
> >> without breaki
On 21.10.18 21:04, Manu wrote:
On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
wrote:
On 21.10.18 17:54, Nicholas Wilson wrote:
As soon as that is done, you've got a data race with the other
existing unshared aliases.
You're in @trusted code, that is the whole point. The onu
On Monday, 22 October 2018 at 00:32:35 UTC, Timon Gehr wrote:
This only works if untrusted programmers (i.e. programmers who
are only allowed to write/modify @safe code) are not allowed to
change your class. I.e. it does not work.
This is the basis of the current @safe/@trusted/@system model.
On Sun, Oct 21, 2018 at 5:35 PM Timon Gehr via Digitalmars-d
wrote:
>
> On 21.10.18 20:46, Manu wrote:
> >> Shared data is only useful if, at some point, it is read/written,
> >> presumably by
> >> casting it to unshared in @trusted code. As soon as that is done, you've
> >> got a
> >> data race
On Monday, 22 October 2018 at 00:38:33 UTC, Timon Gehr wrote:
I just did,
Link please?
On 10/21/2018 4:12 PM, Nicholas Wilson wrote:
On Sunday, 21 October 2018 at 21:32:14 UTC, Walter Bright wrote:
On 10/21/2018 2:08 PM, Walter Bright wrote:
On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
Yes, but the problem you describe is arises from implicit conversion in the
other direction,
On Sun, Oct 21, 2018 at 5:50 PM Walter Bright via Digitalmars-d
wrote:
>
> On 10/21/2018 4:12 PM, Nicholas Wilson wrote:
> > On Sunday, 21 October 2018 at 21:32:14 UTC, Walter Bright wrote:
> >> On 10/21/2018 2:08 PM, Walter Bright wrote:
> >>> On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
>
On 22.10.18 02:46, Nicholas Wilson wrote:
On Monday, 22 October 2018 at 00:38:33 UTC, Timon Gehr wrote:
I just did,
Link please?
https://forum.dlang.org/post/pqii8k$11u3$1...@digitalmars.com
On 22.10.18 02:45, Manu wrote:
On Sun, Oct 21, 2018 at 5:35 PM Timon Gehr via Digitalmars-d
wrote:
On 21.10.18 20:46, Manu wrote:
Shared data is only useful if, at some point, it is read/written, presumably by
casting it to unshared in @trusted code. As soon as that is done, you've got a
data
On Sun, Oct 21, 2018 at 5:40 PM Timon Gehr via Digitalmars-d
wrote:
>
> On 21.10.18 21:04, Manu wrote:
> > On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
> > wrote:
> >>
> >> On 21.10.18 17:54, Nicholas Wilson wrote:
> >>>
> As soon as that is done, you've got a data race with
On Monday, 22 October 2018 at 00:46:04 UTC, Walter Bright wrote:
That's what I was referring to, and Manu's example. It doesn't
work, as I pointed out.
I'm pretty sure it does, but please repeat it.
We will eventually. This started as a "please point out any
problems with this" and has probab
On Sun, Oct 21, 2018 at 5:55 PM Timon Gehr via Digitalmars-d
wrote:
>
> On 22.10.18 02:45, Manu wrote:
> > On Sun, Oct 21, 2018 at 5:35 PM Timon Gehr via Digitalmars-d
> > wrote:
> >>
> >> On 21.10.18 20:46, Manu wrote:
> Shared data is only useful if, at some point, it is read/written,
> >
On Monday, 22 October 2018 at 00:55:00 UTC, Timon Gehr wrote:
On 22.10.18 02:46, Nicholas Wilson wrote:
On Monday, 22 October 2018 at 00:38:33 UTC, Timon Gehr wrote:
I just did,
Link please?
https://forum.dlang.org/post/pqii8k$11u3$1...@digitalmars.com
That contains no code.
Not all of
On Sun, 21 Oct 2018 17:35:38 -0700, Manu wrote:
> On Sun, Oct 21, 2018 at 3:15 PM Neia Neutuladh via Digitalmars-d
> wrote:
>> If we only used your proposal and only used @safe code, we wouldn't
>> have any data races, but that's only because we wouldn't have any
>> shared data. We'd have shared
On Monday, 22 October 2018 at 00:22:19 UTC, Manu wrote:
On Sun, Oct 21, 2018 at 2:35 PM Walter Bright via Digitalmars-d
wrote:
On 10/21/2018 2:08 PM, Walter Bright wrote:
> On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
>> Yes, but the problem you describe is arises from implicit
>> conversio
On 10/21/2018 5:54 PM, Manu wrote:
Would you please respond to my messages, and specifically, respond to
the code that I presented to you in response to your broken example.
Or any of my earlier fragments throughout this thread. I've shared
quite a few, and so far, nobody has ever produced a crit
On 10/21/2018 11:58 AM, Timon Gehr wrote:
[...]
Thank you, Timon, for a nice explanation of what I was trying to express.
On Mon, Oct 22, 2018 at 12:50 AM Walter Bright via Digitalmars-d
wrote:
>
> On 10/21/2018 5:54 PM, Manu wrote:
> > Would you please respond to my messages, and specifically, respond to
> > the code that I presented to you in response to your broken example.
> > Or any of my earlier fragments throu
Third time's the charm maybe?
- repeated, 3rd time
On Sun., 21 Oct. 2018, 2:55 am Walter Bright via Digitalmars-d,
wrote:
>
> On 10/20/2018 11:24 AM, Manu wrote:
> > This is an unfair dismissal.
>
> It has nothing at all to do with fairness. It is
On Mon, Oct 22, 2018 at 12:55 AM Walter Bright via Digitalmars-d
wrote:
>
> On 10/21/2018 11:58 AM, Timon Gehr wrote:
> > [...]
>
> Thank you, Timon, for a nice explanation of what I was trying to express.
You removed whatever comment you're referring to.
I don't understand any of Timon's posts i
On 10/22/2018 1:42 AM, Manu wrote:
You removed whatever comment you're referring to.
If your newsreader cannot find the antecedent, you badly need to use a better
one. Thunderbird handles this rather well, there's no reason to use an inferior one.
Or just click the <- button:
https://digita
On 10/22/2018 1:34 AM, Manu wrote:
I posted it, twice... 2 messages, back to back, and you're responding
to this one, and not that one. I'll post it again...
Posting it over and over is illustrative of the failure of posting proposal
documents to the n.g. instead of posting it as a DIP which
On 22/10/2018 10:28 PM, Walter Bright wrote:
On 10/22/2018 1:34 AM, Manu wrote:
I posted it, twice... 2 messages, back to back, and you're responding
to this one, and not that one. I'll post it again...
Posting it over and over is illustrative of the failure of posting
proposal documents to
On Mon, Oct 22, 2018 at 2:30 AM Walter Bright via Digitalmars-d
wrote:
>
> On 10/22/2018 1:34 AM, Manu wrote:
> > I posted it, twice... 2 messages, back to back, and you're responding
> > to this one, and not that one. I'll post it again...
>
>
> Posting it over and over is illustrative of the fai
On 22.10.18 02:54, Manu wrote:
On Sun, Oct 21, 2018 at 5:40 PM Timon Gehr via Digitalmars-d
wrote:
On 21.10.18 21:04, Manu wrote:
On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
wrote:
On 21.10.18 17:54, Nicholas Wilson wrote:
As soon as that is done, you've got a data rac
On Monday, 22 October 2018 at 00:22:19 UTC, Manu wrote:
No no, they're repeated, not scattered, because I seem to have
to keep repeating it over and over, because nobody is reading
the text, or perhaps imaging there is a lot more text than
there is.
...
You mean like every post in opposition
On Monday, 22 October 2018 at 10:26:14 UTC, Timon Gehr wrote:
---
module borked;
void atomicIncrement(int* p)@system{
import core.atomic;
atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
}
struct Atomic(T){
private T val;
void opUnary(string op : "++")() shared @trusted {
On 22.10.18 12:26, Timon Gehr wrote:
---
module borked;
void atomicIncrement(int* p)@system{
import core.atomic;
atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
}
struct Atomic(T){
private T val;
void opUnary(string op : "++")() shared @trusted {
atomicIncrement(ca
On 22.10.18 14:39, Aliak wrote:
On Monday, 22 October 2018 at 10:26:14 UTC, Timon Gehr wrote:
---
module borked;
void atomicIncrement(int* p)@system{
import core.atomic;
atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
}
struct Atomic(T){
private T val;
void opUnary(string op :
On Monday, 22 October 2018 at 10:26:14 UTC, Timon Gehr wrote:
module borked;
void atomicIncrement(int* p)@system{
import core.atomic;
atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
}
struct Atomic(T){
private T val;
void opUnary(string op : "++")() shared @trusted {
at
On 22.10.18 03:01, Manu wrote:
On Sun, Oct 21, 2018 at 5:55 PM Timon Gehr via Digitalmars-d
wrote:
On 22.10.18 02:45, Manu wrote:
On Sun, Oct 21, 2018 at 5:35 PM Timon Gehr via Digitalmars-d
wrote:
On 21.10.18 20:46, Manu wrote:
Shared data is only useful if, at some point, it is read/wri
On 22.10.18 15:26, Simen Kjærås wrote:
Here's the correct version:
module atomic;
void atomicIncrement(int* p) @system {
import core.atomic;
atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
}
struct Atomic(T) {
// Should probably mark this shared for extra safety,
// but it
On Monday, 22 October 2018 at 13:40:39 UTC, Timon Gehr wrote:
module reborked;
import atomic;
void main()@safe{
auto a=new Atomic!int;
import std.concurrency;
spawn((shared(Atomic!int)* a){ ++*a; }, a);
++a.tupleof[0];
}
Finally! Proof that MP is impossible. On the other hand,
On Monday, 22 October 2018 at 00:22:19 UTC, Manu wrote:
On Sun, Oct 21, 2018 at 2:35 PM Walter Bright via Digitalmars-d
wrote:
Then I don't know what the proposal is. Pieces of it appear to
be scattered over numerous posts, mixed in with other text,
No no, they're repeated, not scattered, b
On 22.10.18 16:09, Simen Kjærås wrote:
On Monday, 22 October 2018 at 13:40:39 UTC, Timon Gehr wrote:
module reborked;
import atomic;
void main()@safe{
auto a=new Atomic!int;
import std.concurrency;
spawn((shared(Atomic!int)* a){ ++*a; }, a);
++a.tupleof[0];
}
Finally! Proof th
On Monday, 22 October 2018 at 00:22:19 UTC, Manu wrote:
On Sun, Oct 21, 2018 at 2:35 PM Walter Bright via Digitalmars-d
wrote:
On 10/21/2018 2:08 PM, Walter Bright wrote:
> On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
>> Yes, but the problem you describe is arises from implicit
>> conversio
On Monday, 22 October 2018 at 14:31:28 UTC, Timon Gehr wrote:
On 22.10.18 16:09, Simen Kjærås wrote:
On Monday, 22 October 2018 at 13:40:39 UTC, Timon Gehr wrote:
module reborked;
import atomic;
void main()@safe{
auto a=new Atomic!int;
import std.concurrency;
spawn((shared(Atomic!i
On Mon, Oct 22, 2018 at 3:30 AM Timon Gehr via Digitalmars-d
wrote:
>
> On 22.10.18 02:54, Manu wrote:
> > On Sun, Oct 21, 2018 at 5:40 PM Timon Gehr via Digitalmars-d
> > wrote:
> >>
> >> On 21.10.18 21:04, Manu wrote:
> >>> On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d
> >>> wr
On Mon, Oct 22, 2018 at 4:50 AM Stanislav Blinov via Digitalmars-d
wrote:
>
> On Monday, 22 October 2018 at 00:22:19 UTC, Manu wrote:
>
> > No no, they're repeated, not scattered, because I seem to have
> > to keep repeating it over and over, because nobody is reading
> > the text, or perhaps imag
On Mon, Oct 22, 2018 at 6:00 AM Timon Gehr via Digitalmars-d
wrote:
>
> On 22.10.18 12:26, Timon Gehr wrote:
> > ---
> > module borked;
> >
> > void atomicIncrement(int* p)@system{
> > import core.atomic;
> > atomicOp!("+=",int,int)(*cast(shared(int)*)p,1);
> > }
> >
> > struct Atomic(T)
201 - 267 of 267 matches
Mail list logo
