Threading Questions

[bitwise via Digitalmars-d-learn]

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