These are chat archives for jdubray/sam
those will be executed in parallel, and their proposals merged into a single one
yes, that's the way to do it.
I don't have a final answer, but at least what's comforting to me is that the synchronization mechanism is rather trivial.
True, I have accepted that this is just the nature of concurrency, and that you have apply it with care. Similar to what eventual consistent databases give you. And there you can define application synchronisation points too, via stronger consistency.
So I can see where the abstract functional mindset comes from, where you want to hide the PC by default, to let the compiler give you performance gains. I find that for a UI the default should be the "sequential" approach, since humans interact with it. In UX I saw that such "sequential" UIs help guide the user, so they do not have to keep the application semantics in their heads all the time. This is what I found interesting about Domain Driven design.
@sladiri just to be clear:
But again, sometimes you cannot avoid concurrency.
the idea behind using the bakery algorithm is actually to avoid using it when it will be difficult to reason about, i.e. in the model. The model MUST-BE synchronized. So you have only two choices:
I like option 2 better!
I just stated the obivous in my comment, that concurrent systems are just more complicated than non-concurrent ones. :) So if you can avoid distribution, you should. Maybe I am not seeing the bigger picture yet, but I see SAM as a good pattern to design a UI, and that you should avoid concurrency for the UI for a good UX anyway. If the model or actions use concurrency "behind the scenes", that is fine, because it is invisible.
I do not know Petri nets, other from a comment from Carl Hewitt, where he explains that they are not physical, that there have to occur things simultaneously in different locations.