On Tuesday, July 31, 2012 11:41:19 maarten van damme wrote: > I now tried to bring it to the next level, using concurrency to bread > a couple of populations and make the best solutions migrate between > them. > But, to use concurrency in D, one has to continually cast between > immutable, cast immutable away, .... > Not only that, casting away from immutable (or too, the error message > is not informative at all) you get error's along the line of "opEquals > doesn't work with immutable arguments"... > > Why is it that cumbersome? It seems like D took a good idea and ruined > it with all that const-stuff. > > I have the feeling that I've completely missed the whole idea on how > concurrency in D should work. Is it normal that you have to either > mess with immutable or with the broken shared? > Am I implementing everything wrong?
To pass something across threads, it either needs to be a value type, or shared, or immutable. Unfortunately, shared doesn't work std.concurrency right now though, so you're stuck using immutable. What we really need is a way to indicate that ownership is being passed from one thread to another, but that can't really be done with the current type system. However, there are probably tweaks that can be made to make it more pleasant to deal with. As for "messing it up with const", immutability (and therefore const) is a core part of D's threading model. By making everything thread-local by default, you then need a way to share instances across threads, and that requires shared (and immutable is implicitly shared). And with immutable, that can be done much more efficiently, because then the compiler doesn't have to worry about multiple threads screwing with the variable. So, the situation isn't perfect and still needs some work, but the basic idea is solid and does work, even if it deosn't yet work quite as well as we'd like. - Jonathan M Davis
