BCS, el 28 de mayo a las 15:57 me escribiste: > Hello Leandro, > > >Jason House, el 28 de mayo a las 08:45 me escribiste: > >>I'm really surprised by the lack of design discussion in this thread. > >>It's amazing how there can be huge bursts of discussion on which > >>keyword to use (e.g. manifest constants), but then complete silence > >>about major design decisions like thread safety that defines new > >>transitive states and a bunch of new keywords. The description even > >>made parallels to the (previously?) unpopular const architecture. > >I just find the new "thread-aware" design of D2 so complex, so twisted > >that I don't even know where to start. I think the solution is way > >worse than the problem here. That's why I don't comment at all. > > I get the impression, from what little I known about threading, that it > is likely you are under estimating the complexity of the threading > problem. I get the feeling that *most* non-experts do (either that, or > they just assume it more complex than they want to deal with).
I guess all depends on the kind of fine granularity you want. I work on a distributed application, so threading is not very tempting for me, I get to use the multi-cores by splitting the work among processes, not threads, because I need "location-transparency" (I don't care if the process I'm communicating with runs in the same computer or not, so things like "move semantics" are not interesting for me). Sometimes I need some threading support, for example to be able to receive queries and do some I/O intensive stuff in the same thread, but the thread-communication I need for that is so trivial, using simple mutexes works just fine. And I never needed so much performance to think about lock-free communication either (mutexes are really fast in Linux). I guess threading complexity is proportional to the complexity of the design. If your design is simple, concurrency is simple. Is really hard to get a deadlock in a simple design. Races are a little trickier, but they are inherent to some kind of problems, so there is not a lot to do about that, you have to see problem by problem and try to get a good design to handle them well. > >I think D duplicate functionality. For "safe" concurrency I use > >processes and IPC (I have even more guarantees that D could ever give > >me). That's all I need. I don't need a huge complexity in the language > >for that. And I think D2 concurrency model is still way too low level. > > You are crazy! processes+IPC only works well if either the OS supports > very fast IPC (IIRC none do aside from shared memory and now we are back > where we started) or the processing between interaction is very long. The later is my case =) > Everything is indicating that shared memory multi-threading is where > it's all going. Maybe, I'm just saying why I don't comment on D2 concurrency model. I find it too complex for my needs (i.e. for what I know, I won't give my opinion about things I don't know/use). -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
