On Friday, 25 September 2015 at 15:19:27 UTC, bitwise wrote:
> I know that all global variables are TLS unless explicitly marked as 'shared', but someone once told me something about 'shared' affecting member variables in that accessing them from a separate thread would return T.init instead of the actual value... or something like that. This seems to be wrong(thankfully).

T.init is returned for TLS variable when accessed from a thread for which it wasn't initialized.

On Tuesday, 29 September 2015 at 19:10:58 UTC, Steven Schveighoffer wrote:
>
> An object that implements the Monitor interface may not actually be a mutex. For example, a pthread_cond_t requires a pthread_mutex_t to operate properly.

Right! I feel like I should have caught the fact that ConditionVariable still has to use pthread_cond_t under the hood, and adopts all of it's behaviour and requirements as a result.

> 4. Technically, you shouldn't access member variables that are GC allocated from a dtor. I know it's a struct, but structs can be GC allocated as well.

Right.... forgot about that.

GC's are really beginning to get on my nerves.. IMO, RAII for GC is a horrible tradeoff.

I'm still not sure I would like Rust, but their memory model is making it a very enticing proposition. I'm almost at the point where I just don't care how much convenience, or familiarity D can offer in other areas.. Its starting to seem like none of it is worth it with a GC-based memory model standing in the way. Maybe this is an exageration...D has a lot of great features..but it's the net benefit that will ultimately determine whether or not people use D.

I use C#(garbage collected) for making apps/games, and while, _in_theory_, the GC is supposed to protect you from leaks, memory is not the only thing that can leak. Threads need to be stopped, graphics resources need to be released, etc.. So when I can't rely on RAII to free these things, I need to free them explicitly, which basically puts me right back where I started.

Anyways, I realize this will probably be buried 3 pages deep in D-Learn by Monday, but at least I feel better :)

    Bit

On Tuesday, 29 September 2015 at 23:20:31 UTC, Steven Schveighoffer wrote:
>
> yeah, that could probably be done. One thing to note is that these classes are from ages ago (probably close to 10 years). New API suggestions may be allowed.
>
>
> -Steve

I'm still thinking about my last rant, here... So by new API, do you mean just adding a couple of new functions, or rewriting a new Condition class(as is the plan for streams)?

Since D is moving towards a phobos with no GC, what will happen to things that are classes like Condition and Mutex?

If DIP74 were implemented, Condition and Mutex could be made ref counted, but DIP74 seems like something that will be very complicated, and may not happen for a long time.

So the only other alternative is to make it a struct, but for a Mutex, that would prevent you from doing this:

Mutex m = new Mutex();
synchronized(m) { }

I also don't mind the way that the current streams are made up of a class hierarchy.

Although inheritance is overused sometimes, I don't think it's bad. But, if I'm correct about the current trend in D, it seems any new stream stuff will end up getting flattened into some template/struct solution.

Any comments on this?

Thanks,

   Bit

On Wednesday, 30 September 2015 at 10:32:01 UTC, Jonathan M Davis wrote:
> On Tuesday, September 29, 2015 22:38:42 Johannes Pfau via Digitalmars-d-learn wrote:
>> [...]
>
> What I took from the answers to that SO question was that in general, it really doesn't matter whether a condition variable has spurious wakeups. You're going to have to check that the associated bool is true when you wake up anyway. Maybe without spurious wakeups, it wouldn't be required if only one thread was waiting for the signal, but you'd almost certainly still need an associated bool in case it becomes true prior to waiting. In addition, if you want to avoid locking up your program, it's ferquently the case that you want a timed wait so that you can check whether the program is trying to exit (or at least that the thread in question is being terminated), and you'd need a separate bool in that case as well so that you can check whether the condition has actually been signaled. So, ultimately, while spurious wakeups do seem wrong from a correctness perspective, when you look at what a condition variable needs to do, it usually doesn't matter that spurious wakeups exist, and a correctly used condition variable will just handle spurious wakeups as a side effect of how it's used.
>
> - Jonathan M Davis

Yea, I guess you're right. The class in the example I posted was a crude reproduction of something I'm using right now in another project:

http://codepad.org/M4fVyiXf

I don't think it would make a difference whether it woke up randomly or not. I've been using this code regularly with no problems.

   Bit

On Sunday, October 04, 2015 14:42:48 bitwise via Digitalmars-d-learn wrote:
> Since D is moving towards a phobos with no GC, what will happen to things that are classes like Condition and Mutex?

Phobos and druntime will always use the GC for some things, and some things just plain need classes. Rather, we're trying to make it so that Phobos does not use the GC when it doesn't need to use the GC as well reduce how much the GC is required for stuff like string processing where lazy ranges can be used instead in many cases.

As for Condition and Mutex specifically, I don't know whey they were ever classes except perhaps to take advantage of the monitor in Object. Maybe they'll get changed to structs, maybe they won't, but most D code is thread-local, and most of the code that isn't is going to use message passing, which means that explicit mutexes and conditions are unnecessary. So, most code won't be impacted regardless of what we do with Condition and Mutex.

Regardless, I doubt that anything will be done with Condition or Mutex until shared is revisted, which is supposed to happen sometime soon but hasn't happened yet. What happens with shared could completely change how Condition and Mutex are handled (e.g. they don't support shared directly even though they should probably have most of their members marked with shared, because Sean Kelly didn't want to be doing anything with shared that he'd have to change later).

- Jonathan M Davis

On Monday, 5 October 2015 at 00:23:21 UTC, Jonathan M Davis wrote:
> On Sunday, October 04, 2015 14:42:48 bitwise via Digitalmars-d-learn wrote:
>> Since D is moving towards a phobos with no GC, what will happen to things that are classes like Condition and Mutex?
>
> Phobos and druntime will always use the GC for some things, and some things just plain need classes. Rather, we're trying to make it so that Phobos does not use the GC when it doesn't need to use the GC as well reduce how much the GC is required for stuff like string processing where lazy ranges can be used instead in many cases.

I was under the impression that the idea was to _completely_ eliminate the GC. It says in Andre's 2015H1 vision statement:
"We aim to make the standard library usable in its entirety without a garbage collector."

I understand the allocation/freeing of memory is expensive, but I thought the actual sweep of the GC was a problem too, and that disabling the GC to avoid the sweep was the plan for some people. I don't know how long D's GC takes to sweep, but even a 5ms pause would be unacceptable for a performance intensive game.

I guess if you use @nogc properly though, you could still safely turn off the GC, right?


> As for Condition and Mutex specifically, I don't know whey they were ever classes except perhaps to take advantage of the monitor in Object. Maybe they'll get changed to structs, maybe they won't, but most D code is thread-local, and most of the code that isn't is going to use message passing, which means that explicit mutexes and conditions are unnecessary. So, most code won't be impacted regardless of what we do with Condition and Mutex.

You may be right. I wrote a simple download manager in D using message passing. It was a little awkward at first, but in general, the spawn/send/receive API seems very intuitive. It feels awkward because the data you're working with is out of reach, but I guess it's safer that way.

> Regardless, I doubt that anything will be done with Condition or Mutex until shared is revisted, which is supposed to happen sometime soon but hasn't happened yet. What happens with shared could completely change how Condition and Mutex are handled (e.g. they don't support shared directly even though they should probably have most of their members marked with shared, because Sean Kelly didn't want to be doing anything with shared that he'd have to change later).
>
> - Jonathan M Davis

I'm not sure what's going to be done with shared, but I do think it's annoying that you can't do this:

shared Array!int numbers;

someThread... {
    numbers.clear(); // 'clear' is not shared
}

So this means that on top of the already ridiculous number of attributes D has, now you have to mark everything as shared too =/

    Bit

On Monday, 5 October 2015 at 17:40:24 UTC, bitwise wrote:
> You may be right. I wrote a simple download manager in D using message passing. It was a little awkward at first, but in general, the spawn/send/receive API seems very intuitive. It feels awkward because the data you're working with is out of reach, but I guess it's safer that way.

Any possibility of a blog post on your experience of doing so ? ;)  [I should start writing some directly, but for time being, until I have my blog up and running again, I write from time to time on Quora].  A few minutes of writing now and then can have a remarkably big impact as well as clarifying your own thoughts, and the time invested is amply repaid, even viewed from a narrowly self-interested perspective.

I had same experience with learning message passing.  Feels like learning to eat with chopsticks in the beginning, but soon enough it feels much more civilised when it's the right tool for the job.

On 10/5/15 1:40 PM, bitwise wrote:
> On Monday, 5 October 2015 at 00:23:21 UTC, Jonathan M Davis wrote:
>> On Sunday, October 04, 2015 14:42:48 bitwise via Digitalmars-d-learn
>> wrote:
>>> Since D is moving towards a phobos with no GC, what will happen to
>>> things that are classes like Condition and Mutex?
>>
>> Phobos and druntime will always use the GC for some things, and some
>> things just plain need classes. Rather, we're trying to make it so
>> that Phobos does not use the GC when it doesn't need to use the GC as
>> well reduce how much the GC is required for stuff like string
>> processing where lazy ranges can be used instead in many cases.
>
> I was under the impression that the idea was to _completely_ eliminate
> the GC. It says in Andre's 2015H1 vision statement:
> "We aim to make the standard library usable in its entirety without a
> garbage collector."

No, the plan is to allow the user to choose how he wants to allocate. Many pieces of phobos make the assumption that the GC is fair game. I think the plan is to make those pieces instead allocate on the stack and provide a mechanism to move that allocation to the GC (Walter's Dconf talk was about this), or accept an allocator to use as a mechanism for allocating memory.

-Steve

On Monday, 5 October 2015 at 20:18:18 UTC, Laeeth Isharc wrote:
> On Monday, 5 October 2015 at 17:40:24 UTC, bitwise wrote:
>> You may be right. I wrote a simple download manager in D using message passing. It was a little awkward at first, but in general, the spawn/send/receive API seems very intuitive. It feels awkward because the data you're working with is out of reach, but I guess it's safer that way.
>
> Any possibility of a blog post on your experience of doing so ? ;)  [I should start writing some directly, but for time being, until I have my blog up and running again, I write from time to time on Quora].  A few minutes of writing now and then can have a remarkably big impact as well as clarifying your own thoughts, and the time invested is amply repaid, even viewed from a narrowly self-interested perspective.

Unfortunately, my time is limited right now. I do have another project, which I've decided will either be finished or discarded by the dawn of 2016. So in the near future, I should have more time for other things.

> I had same experience with learning message passing.  Feels like learning to eat with chopsticks in the beginning, but soon enough it feels much more civilised when it's the right tool for the job.

I like the way my Worker class works because when I don't need the thread anymore, I can simply discard the object that represents the thread. As long as the Worker object is higher up on the stack than anything it's working on, all is well, and the concept of spawn/join is not visible while programming. This works out ok, because while the jobs I'm doing are slow enough to make a UI thread lag, they aren't long-running enough to where waiting for the Worker's thread to join in the destructor becomes a problem. There may be a small lag as the Worker's destructor waits for the last job to finish and the thread to join, but it's only happens once in the lifetime of the worker, so it's not a big deal.

If care is not taken, the above could be subject to these problems:
1) shared memory corruption
2) worker accessing dead memory if it's placed on the stack below what it's working on
3) queueing a long running task could freeze the program on ~Worker()

If you're moving or copying data into a thread, then returning the result(which can be ignored) I think most of the above can be solved.

It's still a bit foreign to me though, and C++ has no such construct yet afaik. I read a bit about std::future and so on, but I'm not sure if they're standard yet. The biggest blocker though, is that the project I'm using that Worker class in is a Unity3D plugin. They only very recently updated their iOS libs to allow libc++ > 98....

    Bit

On Sunday, 4 October 2015 at 04:24:55 UTC, bitwise wrote:
> I use C#(garbage collected) for making apps/games, and while, _in_theory_, the GC is supposed to protect you from leaks, memory is not the only thing that can leak. Threads need to be stopped, graphics resources need to be released, etc.

XNA doesn't manage graphics resources?

On Monday, 5 October 2015 at 17:40:24 UTC, bitwise wrote:
> I'm not sure what's going to be done with shared, but I do think it's annoying that you can't do this:
>
> shared Array!int numbers;
>
> someThread... {
>     numbers.clear(); // 'clear' is not shared
> }
>
> So this means that on top of the already ridiculous number of attributes D has, now you have to mark everything as shared too =/

That's illegal in other languages too except that they allow you to do it. If you want concurrent collections, you must code them separately: https://msdn.microsoft.com/en-us/library/system.collections.concurrent%28v=vs.110%29.aspx