Bartosz Milewski Missing post

[Leandro Lucarella]

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)
----------------------------------------------------------------------------