Microsoft concurrency work

[Alex Arnon]

On 2/14/06, Vlad Dumitrescu <vlad_dumitrescu@REDACTED> wrote:
>
> Hi,
>
> > From: Sean Hinde
> > One thing that struck me is that they effectively have a
> > receive construct which says:
> >
> > receive
> >      {Ref1, Msg1} and {Ref2, Msg2} ->
> >          do_code_only_when_both_arrived();
> >      Other ->
> >          handle_other_message()
> > end
> >
> > I know we can build this in Erlang, but not without some
> > faffing to track what has already arrived.
>
> Actually, they can even synchronize on messages in different mailboxes,
> which works fine because mailboxes aren't processes (in the Erlang sense).
> Powerful, but IMHO creating more problems than solving (at least when
> comparing to Erlang :-).
>
> Except for the fact that their handlers are dynamic (which we don't have),
> this type of handlers could be simulated by  something like
>         Pid = spawn(fun() ->
>                 receive
>                         {Ref1, Msg1} ->
>                                 receive {Ref2, Msg2} ->
>                                         do_code_only_when_both_arrived()
>                                 end
>                 end),
>         receive
>            {Ref1, Msg1} -> Pid ! {Ref1, Msg1};
>            {Ref2, Msg2} -> Pid ! {Ref2, Msg2};
>                 Other ->
>                         ...
>         end,
> Which actually could work even for Msg1 and Msg2 coming from different
> processes (the problem being how to let them know the value of Pid).
>
>
> Also, I wonder how easy it is to keep track of all handlers that are
> installed on a single port at any moment in time. How am I supposed to
> choose the proper match predicate if I don't know what other predicates
> are
> active on that port? If I don't get a message that I expect, is it because
> it didn't arrive at all, or because some other handler ate it up? *brrr* a
> nightmare to debug...
>
> Comparing to a receive statement, where all cases are explicit, I think my
> bias is clear ;-)
>
> Alternatively, I might have misunderstood everything completely. ;-)
>
> Regards,
> Vlad
>
>
>
IMHO, your bias is well founded. Reading through the Polyphonic C#
whitepaper (nice spin :) ), it seems to me that the approach would mitigate
some of the monitor/mutex/semaphore pain, but ultimately not by much. It
might make that kind of concurrent programming easier in some instances, but
generally it seems to me to be too little, possibly too late.
And not even a mention of Erlang in the whole document. Pfft.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20060214/219332dd/attachment.htm>