Yes, all the synchronization and casting pretty much mandates
that shared data must be behind some kind of abstraction for
better ergonomics and better correctness too.
On 14/7/20 10:45, Dominikus Dittes Scherkl wrote:
This is generally true. Avoid sharing many variables!
Tasks should be as independent from each other as possible. Anything
else is bad design doomed to run into problems sooner or later.
Also there is really almost never a good reason to share
On Tuesday, 14 July 2020 at 07:05:43 UTC, Arafel wrote:
*However*, for this to work, you shouldn't use `shared` member
variables unless absolutely necessary, much less whole `shared`
classes/structs
This is generally true. Avoid sharing many variables!
Tasks should be as independent from each
On 14/7/20 8:13, Kagamin wrote:
---
import std;
shared class TimeCount {
void startClock() {
auto me = cast()this;
me.startTime = Clock.currTime;
}
void endClock() {
auto me = cast()this;
me.endTime = Clock.currTime;
}
void
---
import std;
shared class TimeCount {
synchronized void startClock() {
auto me = cast()this;
me.startTime = Clock.currTime;
}
synchronized void endClock() {
auto me = cast()this;
me.endTime =
On 14/7/20 8:05, Kagamin wrote:
On Monday, 13 July 2020 at 07:26:06 UTC, Arafel wrote:
That's exactly why what I propose is a way to *explicitly* tell the
compiler about it, like @system does for safety.
With __gshared you can opt out from sharing safety, then you're back to
old good C-style
---
import std;
shared class TimeCount {
void startClock() {
auto me = cast()this;
me.startTime = Clock.currTime;
}
void endClock() {
auto me = cast()this;
me.endTime = Clock.currTime;
}
void
On Monday, 13 July 2020 at 07:26:06 UTC, Arafel wrote:
That's exactly why what I propose is a way to *explicitly* tell
the compiler about it, like @system does for safety.
With __gshared you can opt out from sharing safety, then you're
back to old good C-style multithreading.
On 13/7/20 14:18, Steven Schveighoffer wrote:
cast() will remove as little as possible, but for most cases, including
classes and struts, this means the entire tree referenced is now unshared.
Yeah, but the whole lvalue cast looks just non-obvious and ugly to me:
```
cast() foo = bar;
```
On 7/13/20 3:26 AM, Arafel wrote:
On 13/7/20 3:46, Steven Schveighoffer wrote:
On 7/11/20 6:15 AM, Arafel wrote:
What I really miss is some way of telling the compiler "OK, I know
what I'm doing, I'm already in a critical section, and that all the
synchronization issues have been already
On 13/7/20 3:46, Steven Schveighoffer wrote:
On 7/11/20 6:15 AM, Arafel wrote:
What I really miss is some way of telling the compiler "OK, I know
what I'm doing, I'm already in a critical section, and that all the
synchronization issues have been already managed by me".
You do. It's a
On 7/11/20 1:03 AM, Kagamin wrote:
Steven's solution isn't good in the general case
Right, you need to know that SysTime is actually a value type, and so it
can be implicitly copied without problems with aliasing.
In fact, the cast isn't needed to ensure there is no lingering aliasing.
I
On 7/11/20 6:15 AM, Arafel wrote:
Because the system don't know if just this lock is enough to protect
this specific access. When you have multiple locks protecting multiple
data, things can become messy.
Yes.
What I really miss is some way of telling the compiler "OK, I know what
I'm
On 10/7/20 20:30, mw wrote:
On Friday, 10 July 2020 at 17:35:56 UTC, Steven Schveighoffer wrote:
Mark your setTime as shared, then cast away shared (as you don't need
atomics once it's locked), and assign:
synchronized setTime(ref SysTime t) shared {
(cast()this).time = t;
}
I know I
On Friday, 10 July 2020 at 17:18:25 UTC, mw wrote:
On Friday, 10 July 2020 at 08:48:38 UTC, Kagamin wrote:
On Friday, 10 July 2020 at 05:12:06 UTC, mw wrote:
looks like we still have to cast:
as of 2020, sigh.
Why not?
Because cast is ugly.
Implicitly escaping thread local data into
On Friday, July 10, 2020 12:30:16 PM MDT mw via Digitalmars-d-learn wrote:
> On Friday, 10 July 2020 at 17:35:56 UTC, Steven Schveighoffer
>
> wrote:
> > Mark your setTime as shared, then cast away shared (as you
> > don't need atomics once it's locked), and assign:
> >
> > synchronized
On 7/10/20 2:30 PM, mw wrote:
On Friday, 10 July 2020 at 17:35:56 UTC, Steven Schveighoffer wrote:
Mark your setTime as shared, then cast away shared (as you don't need
atomics once it's locked), and assign:
synchronized setTime(ref SysTime t) shared {
(cast()this).time = t;
}
I know I
On Friday, 10 July 2020 at 17:35:56 UTC, Steven Schveighoffer
wrote:
Mark your setTime as shared, then cast away shared (as you
don't need atomics once it's locked), and assign:
synchronized setTime(ref SysTime t) shared {
(cast()this).time = t;
}
I know I can make it work by casting, my
On 7/10/20 1:18 PM, mw wrote:
On Friday, 10 July 2020 at 08:48:38 UTC, Kagamin wrote:
On Friday, 10 July 2020 at 05:12:06 UTC, mw wrote:
looks like we still have to cast:
as of 2020, sigh.
Why not?
Because cast is ugly.
I've also tried this:
```
class A {
SysTime time;
On Friday, 10 July 2020 at 17:18:25 UTC, mw wrote:
On Friday, 10 July 2020 at 08:48:38 UTC, Kagamin wrote:
On Friday, 10 July 2020 at 05:12:06 UTC, mw wrote:
looks like we still have to cast:
as of 2020, sigh.
Why not?
Because cast is ugly.
I've also tried this:
```
class A {
On Friday, 10 July 2020 at 08:48:38 UTC, Kagamin wrote:
On Friday, 10 July 2020 at 05:12:06 UTC, mw wrote:
looks like we still have to cast:
as of 2020, sigh.
Why not?
Because cast is ugly.
I've also tried this:
```
class A {
SysTime time;
synchronized setTime(ref SysTime
On Friday, 10 July 2020 at 05:12:06 UTC, mw wrote:
looks like we still have to cast:
as of 2020, sigh.
Why not?
On Thursday, July 9, 2020 9:01:20 PM MDT mw via Digitalmars-d-learn wrote:
> On Friday, 10 July 2020 at 02:59:56 UTC, mw wrote:
> > Error: template std.datetime.systime.SysTime.opAssign cannot
> > deduce function from argument types !()(SysTime) shared,
> > candidates are:
> >
On Friday, 10 July 2020 at 03:01:20 UTC, mw wrote:
On Friday, 10 July 2020 at 02:59:56 UTC, mw wrote:
Error: template std.datetime.systime.SysTime.opAssign cannot
deduce function from argument types !()(SysTime) shared,
candidates are:
/usr/include/dmd/phobos/std/datetime/systime.d(659,17):
On Friday, 10 July 2020 at 02:59:56 UTC, mw wrote:
Error: template std.datetime.systime.SysTime.opAssign cannot
deduce function from argument types !()(SysTime) shared,
candidates are:
/usr/include/dmd/phobos/std/datetime/systime.d(659,17):
opAssign()(auto ref const(SysTime) rhs)
of
25 matches
Mail list logo
