2

It is the other way around. We first model the system in a certain way, for instance we assume that there is a (or is no) global clock, or we assume that messages arrive or may fail, etc. Once we fix our assumptions, we can ask questions about the system we have characterized: does it allow computations of certain types or not? For instance, if we assume all ...


1

my answer to the first problem would go like this: From a logical perspective, it depends on the actual purpose of the application, however, we should at least ensure safety and liveness, therefore some locking algorithms are appropriate. Since the contest could be very serious (legal consequences in case of booking failure) I would opt for a mutual ...


1

What you pointed out is a possible approach to the problem that is basically a model checking one. Check all possible combinations and observe mutual exclusion is invalidated in case 2 or more processes are in CS. Since Peterson2P satisfies ME no counterexample is ever encountered. To prove properties like mutual exclusion, deadlock freedom, starvation ...


1

The unifying definition is that one part of the system triggers an event in another part of the system, and the triggerer does not know when the event will take place. To put it another way: in a synchronous system, you know when things (will) happen. In an asynchronous system, you don't know when things (will) happen. In event-based programming, a thread ...


1

I'm late to the party but I suppose I can offer my intuition on this. I think of it as a race between threads. The race consists the number of laps = #threads-1. The idea is after each lap, 1 thread is left behind, so at the end of the race, only 1 thread is guaranteed to come out on top. From the perspective of each thread, it looks like below (the comments)...


Only top voted, non community-wiki answers of a minimum length are eligible