Modelling Concurrent Programs as Multi-Player Games of Imperfect Information against Nature
Modellering av Distribuerade System som Multi- Spelar spel med Imperfekt Information mot Naturen
TOBIAS GLIMMERFORS SIMON OLANDER ÅLUND
KTH
SKOLAN FÖR ELEKTROTEKNIK OCH DATAVETENSKAP
Programs as Multi-Player Games of Imperfect
Information against Nature
T. GLIMMERFORS, S. OLANDER
Bachelor in Computer Science Date: June 7, 2020
Supervisor: Dilian Gurov Examiner: Pawel Herman
School of Electrical Engineering and Computer Science Swedish title: Modellering av Distribuerade System som Multi-Spelar spel med Imperfekt Information mot Naturen
Abstract
Concurrent programs exists all around us. Whether someone is liking a photo on a social media platform or whether someone is doing a bank-transaction, concurrency is acting behind the scenes. Due to the nature of concurrent pro- grams having multiple Users, or Threads, a range of different problems can emerge. Some of these problems stem from the limited knowledge of each Thread. Similar to how people use their knowledge to make decisions in ev- eryday life, a Thread’s knowledge of a program’s state can aid the decision of which action to take. An interesting question is thus whether we can model the knowledge of a concurrent system in order to aid the execution of instructions.
In this report we investigate the plausibility of modelling problematic concur- rent programs as games of imperfect information against nature. Successfully modelled programs are analysed from the perspective of each Thread’s dis- tributed knowledge by applying Multi-Player Knowledge Based Subset Con- struction (MKBSC). In this report we have successfully modelled three differ- ent programs that each handle a concurrency-related problem. We have also shown how we can synthesise winning strategies from the knowledge of each Player for two out of three game models.
Sammanfattning
Distribuerade system finns överallt i vardagen. Allt från en gillad bild på so- ciala medier till en genomförd banktransaktion är möjliga på grund av dis- tribuerade system. Distribuerade system är system med fler Användare, eller Trådar, som alla arbetar samtidigt. På grund av denna samtidighet, kan en upp- sjö av olika probelm uppstå. Vissa av dessa problem grundar sig i att systemets Trådar har begränsad kunskap av hela systemet. Precis som när människor an- vänder sin kunskap för att göra val i vardagen, så kan Trådarnas kunskap bidra till vilka instruktioner som ska utföras. Således finns det en intressant fråge- ställning huruvida man kan modellera Trådarnas kunskap, för att förebygga eventuella problem i distribuerade system. I denna rapport undersöker möjlig- heten att modellera Trådarnas kunskap i problematiska distribuerade system som spel med imperfekt information mot naturen. De modeller som lyckas framställas analyseras med ambition att redogöra för Trådens distribuerade förståelse genom att applicera Multi-Player Knowledge Based Subset Con- struction (MKBSC). Vi lyckades modellera tre olika distribuerade program med varsitt problem. Vi kunde utgöra att den kunskap som Trådarna innehade kunde användas för framställandet av vinnande strategier i två av tre modeller.
1 Introduction 1
1.1 Purpose . . . 2
1.2 Problem statement . . . 2
2 Background 3 2.1 Concurrency . . . 3
2.1.1 Problems of concurrency . . . 3
2.2 Types of Games . . . 4
2.2.1 Single-player Games against Nature . . . 4
2.2.2 Multi-player Games . . . 5
2.2.3 Multi-player games against Nature . . . 7
2.3 Games of perfect and imperfect information . . . 7
2.3.1 Games of perfect information . . . 7
2.3.2 Games of impefect information . . . 8
2.4 Knowledge-Based Modelling . . . 9
2.4.1 Knowledge-Based Subset Construction . . . 9
2.4.2 Nested Knowledge . . . 10
2.4.3 Strategy synthesis . . . 13
2.5 Related work . . . 14
2.5.1 Knowledge in systems . . . 14
2.5.2 Knowledge-based programs . . . 15
3 Method 16 3.1 Approach . . . 16
3.2 Limitations . . . 17
4 Results: Shared counter problem 18 4.1 Game model . . . 18
4.2 Nested knowledge . . . 20
v
5 Results: Shared memory problem 23
5.1 Deterministic . . . 23
5.1.1 Game model . . . 23
5.1.2 Nested knowledge . . . 25
5.2 Non-Deterministic . . . 27
5.2.1 Game model . . . 27
5.2.2 Nested knowledge . . . 28
6 Discussion 30 7 Conclusion 32 7.1 Future work . . . 32
Bibliography 33
Appendix 35
Introduction
When someone likes a photo on a social media platform the total number of should likes increase. However, what happens when to two people like the same photo at the same time? The problem stems from the fact that both
“likes“ should be counted, but it is hard to determine which came first. This is an interesting and common problem in the field of computer science called concurrency. The solution for this problem is not trivial and is, in general, rather intricate to solve. However, the question is whether these kinds of prob- lems can be avoided from the get-go?
A reason for why these concurrency problems occur stems from the fact that the Threads, the “Users” of the program, do not know everything. Similar to that no one knows that someone else is liking the same photo, a single Thread does not know what all other Threads are doing. Modern solutions to these concurrency problems are to improve the “internal communication and coor- dination“ between the Threads. In essence these solutions force the Threads to coordinate using some kind of schedule between themselves. But is it pos- sible to avoid the problem, without the need for “internal communication”? Is it possible to use the knowledge of each Thread, in order proactively solve a problematic scenario?
1
1.1 Purpose
The purpose of our report is to investigate the knowledge of concurrent pro- grams by a subset-construction based methodology. We will utilise a transfor- mation called the Multi-Agent Knowledge-Based Subset Construction (MKBSC) to model small idealised concurrent programs as games. Further, this report will also analyse these models to conclude whether certain properties within these concurrent programs can be deduced. We are interested in finding prop- erties that can aid in solving the problematic scenarios that concurrency poses.
We are in essence investigating whether there is some kind of knowledge-based strategy that can be synthesised to avoid these kinds of problems within con- current programs. It is worth noting that strategies already exist for resolving most problems within concurrency, but in this report we investigate an alter- native method of finding a solution.
1.2 Problem statement
We have two research questions:
• How can MKBSC be utilised in order to model small concurrent pro- grams?
• Given a model of such a program, and with the help of the iterated MKBSC. Is it possible to deduce information that is relevant for the study of problems within concurrent programs?
Background
In this chapter we define the terminology that is used throughout the report.
2.1 Concurrency
Concurrent programs are programs which have multiple “points of execution”
that are executed simultaneously. An example of such a program is a multi- threaded program, where all threads are separate programs virtually acting in- dependently. Other examples include front-end users querying a database or an operating system running different applications simultaneously. The threads are separate processes, but they do share memory and information with each other. In this report we explore this shared variable space, but only in simple cases.[1]
2.1.1 Problems of concurrency
Due to the nature of threads sharing parts of the memory space, problems such as race conditions can occur. An example of such a problem is when two threads are executing operations on the same memory space (e.g. the same memory address or register) and the outcome of their actions is inde- terminable. The actions could for example be to write some data to a certain variable, but depending on which thread performs the action first the resulting value of said variable might differ.[1]
3
2.2 Types of Games
The games that we utilise in this report are abstract algebraic objects that model state transitions. This section’s purpose is to define and explain these algebraic objects in more detail.
2.2.1 Single-player Games against Nature
The type of model we are using is defined in terms of ”Games”. In order to define such a ”Game” we are required to define several other abstract objects.
The first object is called a game graph and is defined as a tuple:
G = (V, E, v0)
Where (V, E) is a directed graph and v0is the initial state of the game. We also define each transition to be non-deterministic, which is the nature component of our game model. As the underlying structure is a directed graph we can use the left co-sets of E for some v ∈ V to represent the possible successors of said state v:
vE = {w | (v, w) ∈ E}
The Players of the game invoke a play by moving along the edges of a game graph. Formally we define a play as an infinite sequence π = v0, v1, ... where the pair-wise-consecutive vertices of π are edges in E. Since a play is an infi- nite sequence of vertices, it is interesting to observe the described path through (V, E) at some time t. This spans a sub-sequence of π, which is denoted as the history H. Using the definition of a history, we define a strategy as a function σ : H 7→ V where it maps a history πt = v0, v1, ..., vtto some vt+1∈ V where (vt, vt+1) ∈ vE. If we have the case that πt+1 = πt∪ {σ(πt)}, then we say that π is following the strategy σ.[2]
A game also contains a win-condition, that determines whether the Player have won the play. The win-condition of a game is defined as a set of plays:
W ⊆Y
c
V
There are different types of win-conditions, however in this report only so called reachability win-conditions are of interest. A reachability condition is intuitively described as some target vertex v ∈ V for which each winning-play reaches at some time t.[2]
start
0
1
win
0
+1
0
+1
0
+1
Figure 2.1: A simple game where each state represents the total score of a Player. Each transition either increments or sustains the score, and the win- condition is to get a score of 2.
2.2.2 Multi-player Games
In this report, games with multiple Players are investigated. The definition for a multi-player game is similar for that of a single-player game, with the difference being that each Player can perform a set of plays that may or may not be the same for each Player. This means that instead of having a singleton game G, we have a tuple of games
G =Y
i∈P
Gi
for each Player i in the set of Players P . We have i different starting posi- tions denoted by a subscript such that vi, πi, Hiis the initial position, play and history for Player i respectively.[3]
0 1
2 win
(0,0) (+1,0)
(0,+1)
(+1,+1)
(0,0)
(0,+1) (+1,0)
(+1,+1)
(0,0)
(+1,0) (0,+1) (+1,+1)
Figure 2.2: A simple multi-player game where each state represents the total score of a Player. Each transition either increments or sustains the score. The win-condition is to get a score of either 3 or 4.
Due to the nature of multi-player games, the number of transitions are ex- ponential in the number of Players. Therefore, we concatenate the labels of actions with the same successor vertex to reduce the number of edges of the visualisations. For instance, Figure 2.2 and Figure 2.3 are equivalent repre- sentations of the same game.
0 1
2 win
(0,0) (+1,0), (0,+1)
(+1,+1)
(0,0)
(+1,0), (0,+1)
(+1,+1)
(0,0) (+1,0),(+1,0),(+1,+1)
Figure 2.3: A simplified visualisation of the game in Figure 2.2
2.2.3 Multi-player games against Nature
In Multi-Player games against nature, we have a team of Players co-operating in order to try to achieve a common goal. In the type of games we model, all Players decide on which move to make at the same time. Thereafter, you reach another game state. In order to be able to model games as non-deterministic, the opponent is modelled as an aspect called nature. The nature component can make any of the available moves, and it is not possible to determine, ahead of time, which move the nature will make. When modelling a game, this nature component is not explicitly shown. Rather, it can be seen in the graph when one or more states have the same action leading to more than one resulting state. What this means, is that for a given set of moves by the players, the resulting state can vary.
0
1 2
(0,0)
(0,0)
Figure 2.4: A simple example of a non-deterministic game
Figure 2.4 shows a simple game with the aspect of nature built into the graph.
In this case, there are two players that each can make a move "0". If they make this move in the state 0, they can either end up in state 1 or 2.
2.3 Games of perfect and imperfect informa- tion
In order to investigate the plausibility of modelling certain concurrency prob- lems we have to consider which kind of information each Player (e.g. thread) has at any given time. Due to the nature of concurrency the pair-wise shared information amongst the Players is not perfect. This section presents this in- formation discrepancy in more detail.
2.3.1 Games of perfect information
A game is said to be of perfect information if all Players have complete knowl- edge over each state as well as all actions that can be taken in each state. A
concrete example of such a game is “Chess” since all information about the game can be derived from the current state of the game. In the same way, the games visualised in Figure 2.1 and Figure 2.3 are both games of perfect information.
2.3.2 Games of impefect information
Games of impefect information are somewhat different when compared to games of perfect information. In a game of imperfect information, some infor- mation is hidden from at least one Player. This means that there exists some number of states that are perceived as the same to the Player and that there is no way for the Player to distinguish which state they are currently in among these states. For instance, a game of imperfect information is “Poker” in which you do not know what cards the other players were given or what cards remain in the deck.
A formal definition of games of imperfect information is a “game of perfect information” that includes an observation set Oi, for all Players i. This set Oi
is a partition of the possible states V , defined by an equivalence relation R ⊆ V × V
This relation R equates two states, R(a, b), for some Player, j, if and only if that Player cannot distinguish between a, b. Thus, the set of each R-equivalence class of L is the set of all possible different observations some Player, j, can observe. This is the definition of Oj.[4]
0
1 2
win (0,0)
(+1,0), (0,+1)
(+1,+1) (0,0)
(+1,0), (0,+1)
(+1,+1) 0
(0,0) (+1,0),(+1,0),(+1,+1)
Figure 2.5: This game is defined as the game in Figure 2.3, with the addition that Player 0 is incapable of differentiating between a score of 1 or 2. That is, Player 0 cannot distinguish between two different states. This inability is represented as coloured dotted line with the affected Player’s index as a label.
2.4 Knowledge-Based Modelling
In order to analyse the games from the perspective of understanding each Player’s knowledge, certain transformations are required to be made. This section explains the transformation and tool that we utilise in this report.
2.4.1 Knowledge-Based Subset Construction
A tool used to generate the underlying knowledge of a Player in games of im- pefect information is called Knowledge-Based Subset Construction (KBSC).
This tool transforms a game G of imperfect information against nature into a game GKof perfect information based on the Player’s knowledge.1 We define the game GKas follows:
GK = (VK, EK, vK0 )
Where VK = P(V ) \ {∅} (the power-set of V ), v0K is the initial state of GK and where EK are the edges of the new directed graph (VK, EK). Since VK is the power-set of all possible states of G, we have that GK is a game that
1The “K” of the notation is not an exponent. The “K” is an identifier to differentiate between a game with knowledge and a game.
represents the knowledge of the Player in each of its states. A transition in EK is, instead of being a choice that leads to a new possible outcome, a transition to less or more possible knowledge of the current situation.[5][6]
Multi-Player Knowledge-Based Subset Construction (MKBSC) is a gener- alisation of KBSC presented in [4], where more than a singular Player can be modelled using the same principle. The generalisation is the canonical prod- uct of all Players in a multi-player game of impefect information against nature G. Let (G |i) denote the game generated by Player i:s knowledge, we define the nested knowledge for a multi-player game as follows:
GK =Y
i∈P
(G |i)K
That is, instead of having a some vk ∈ VKrepresent the knowledge of a single Player, we have that vkis a vector containing all the knowledge of all Players for the underlying state of the game G. This means that in every state of a multi-player game with knowledge, GK, each Players’ knowledge is present.
2.4.2 Nested Knowledge
The application of the MKBSC has been explained to yield information, when applied to some game G, of the Player’s knowledge. The resulting game GK is in essence the same game as G, since it describes the underlying game G.
However, in substance GK is a different game defined by a different game graph GK = (VK, EK, vK0 ). This yields the possibility of applying MKBSC once again on GK, resulting in the knowledge-of-knowledge of G, G2K. In- tuitively this means that for each of the states in G2K the possible knowledge of the Players’ knowledge is contained, we call this nested knowledge. An example is shown in Figure 2.7.[4]
Figure 2.6: This graph is the knowledge that each Player has when being in each state of the game described in Figure 2.5. The representation is defined as each state containing two (one for each Player) knowledge-sets, where the contents or these knowledge-sets are what each Player can deduce from the current state. For instance, the state with the contents {1, 2}, {2} is the state (in Figure 2.5) where the score is equal to 2. This is something that Player 1 knows, but something that Player 0 does not know (since we defined in Fig- ure 2.5 that Player 0 cannot differentiate between score 1 and 2); hence the first knowledge-set containing two possible scores, and the second knowledge-set only one score.
Figure 2.7: 2 iterations of MKBSC of the game in Figure 2.5.
In comparison to the game in Figure 2.6, each state in Figure 2.7 contains information of all Players simultaneously. To explain the notation, we take the state with the contents:
{21 − 1, 21 − 2}
{21 − 1}
Similarly to previous iteration, each line displays the knowledge of each Player.
However, the knowledge is now in contrast to previous iteration a multi-set of potential knowledge for each Player. That is, for Player 1 we have the multi-set:
{21 − 1}
Intuitively this means that Player 1, in this state, knows that:
Player 1: I know that the current score in this state is 1. I also know that Player 0 knows that this is either score 1 or 2.
For Player 0 on the other hand, we have {21 − 1, 21 − 2} which is equivalent to:
Player 0: I know that the current score in this state is either 1 or 2.
I also know that Player 1 for sure knows what the score is. But, I do not know whether Player 1 knows that it is 1 or 2.
The notation can be confusing and an alternative notation is something that has been researched.[3] And it turns out that the multi-set of potential knowledge can be defined as so called knowledge-trees.[7] Translating the above notation into this tree-structure can be noted in Figure 2.8.
{2,1}
{1} {2}
{1}
{1} {2}
Figure 2.8: The left-most tree displays the knowledge {21−1, 21−2} of Player 0. Where the root is the knowledge that Player 0 possesses, and the leaves are the knowledge that Player 1 possesses. The right-most tree is the knowledge of Player 1, {21 − 1} with the root representing Player 1’s knowledge and the leaves of Player 0.
As can be noted in Figure 2.8, there are multiple potential knowledge possibil- ities, where each edge encapsulates each such possibility. The rigorous theory of these knowledge-tree-structures are outside of the scope of this report. We merely present the structures to provide an alternative way of understanding the potential knowledge and theory of an iterated MKBSC representation.
2.4.3 Strategy synthesis
The nested knowledge that is retrieved from applying the MKBSC can be used when synthesising winning strategies for the underlying game. The knowl- edge can be used in finding memoryless strategies — strategies that only use the knowledge of the current state.[3] The strategy synthesis can be found by analysing the knowledge of a state and then deciding the next action to take.
The intuitive example above can be used in the synthesis of a strategy, we
present the strategy for the first Player in Table 2.1. The strategy synthesis is in general a difficult problem, and an algorithm for synthesising strategies is not covered in this report.[4]
Order Knowledge State Action (Player 1)
1 {{0-0}, {0-0}} +1
2 {{21-1,21-2}, {21-1}} +1
3 {{21-1,21-2}, {21-2}} 0
Table 2.1: The strategy that Player 1 (from example in Figure 2.5) can follow, synthesised by the second level nested knowledge of Figure 2.7.
2.5 Related work
In this section other works that relate to our study are presented. However, we limit this section to merely provide an overview of their methods and results.
2.5.1 Knowledge in systems
Numerous studies have covered the topic of knowledge in systems. The knowl- edge itself is generally defined in terms of “which state the system or program is in, at some point in time”.[8, 9, 10] As any program is defined by the set of actions or instructions that it can perform, the possible states (and by ex- tension, the possible knowledge) can be modelled. Intuitively, the notion of knowledge is similar to that of “human” knowledge. For instance, when an individual is grocery shopping and learns that a new item has been collected.
The term knowledge becomes more intricate in distributed and concurrent sys- tems however. This intricacy can be explained as a hierarchy of different types of knowledge. Where one type is defined as: for a non-trivial subset of the Players in a concurrent system, this subset is said to have a distributed knowl- edge. Which is knowledge only shared among this subset. Further, common knowledge is the highest hierarchy of type of knowledge, and is defined as the knowledge of all Players.2[9] The latter type of knowledge is however, gener- ally impossible to attain in a distributed system.[8]
2In the singular case, the only non-trivial subset of Players is the singular Player. In that case there is no distinction between distributed and common knowledge.
2.5.2 Knowledge-based programs
An application of the concept of knowledge in systems, is the construction of knowledge-based programs. The definition of these models are based in the notion of protocols. A protocol is a function that maps states to actions, where a Player uses a protocol to retrieve which subsequent action to perform.[11, 12]
Intuitively, a protocol is a recipe that explains which is the next ingredient too add to a stew. The term for knowledge-based protocol is also defined as the canonical function that maps knowledge to actions, where the Player’s knowl- edge is the argument instead of its current state.[10] However, the definition of knowledge-based programs is a syntactical program where there are a se- ries of tests that a Player performs. The Player both performs standard tests on its local state and knowledge tests on its “knowledge state”. In essence this maps the Player’s current existence (both physical and meta-physical) to some protocol.[12]
Method
In this chapter we describe the tools used to answer our research questions.
We also describe the limitations of the research.
3.1 Approach
In order to apply MKBSC on concurrent programs, we have described the concurrent program as a multi-player game of imperfect information against nature (MGIN). We constructed three different concurrent programs in terms of a MGIN, which have then been modelled using MKBSC. The modelling has been visualised by the ”MKBSC-tool” developed by Jacobsson and Nylén[5].
Further, our approach for the second research question has been to utilise the mentioned MKBSC-tool and iterate the knowledge of each Player. Each iter- ation of knowledge provides each state with more information about the other Players’ knowledge. However, at some point, the iterated graphs become iso- morphic with the graph from a previous iteration. In short, an isomorphism implies that we cannot derive any truly new knowledge for subsequent iter- ations. That is, two graphs that are isomorphic can have different structures, but the knowledge in the graphs will merely be a reformulation of the previous iteration’s knowledge. The subsequent analysis have, depending on the mod- elled concurrent program, decided whether certain information of each Player could be deduced. Due to a lack of automated methods for synthesising strate- gies, the analysis has been made by ourselves by observing the iterated game graphs.
16
3.2 Limitations
Due to the nature of the MKBSC, the number of possible knowledge-states are exponential in the number of game-states (See 2.4.1). Therefore, we have lim- ited our concurrent program such that generating the expanded MKBSC-game can be done in reasonable time, as well as having the resulting graph remain manageable (not to large and complex). An isomorphism is a favourable out- come since it would mean that we have “peaked“ in terms of possible knowl- edge in the system, but for some of the games the resulting iterated-graph were shown to be too complex for any relevant analysis to be conducted. Therefore, we have limited ourselves to only working with smaller graphs.
Similarly, due to the state-explosion, we have chosen to model rather abstract concurrent programs that are simplistic. These concurrent programs are easy in terms of number of possible states and actions. However, the programs have been chosen so that their simplicity does not affect their relevance in describing common scenarios in concurrent programs.
Results: Shared counter prob- lem
Due to the nature of concurrency, a problem that can occur is when a shared register or variable is used for keeping track of a shared state. For instance a problem where two threads or processes increment the same counter-variable.
Such a case could arise when two end-users like the same photo on a social media platform. The expected case is that both “like-actions” are registered and counted as separate events. However, since these actions are handled con- currently among the threads, there is a possibility that one thread increments a deprecated value. The result would be be that we have a race condition where the outcome (number of displayed likes of the photo) is uncertain.
4.1 Game model
The game model that we will define will model the possible states that a counter variable count, can exist in. The possible states that count can exist in are:
count ∈ {0, 1, ∗, win}
The states 0, 1 are the possible values count can contain. The state “*” repre- sents the state where a race condition has occurred, which means that we are uncertain what the value of count is. The state “win” is the win-condition. The game will contain two Players (threads): 0, 1. These two Players can execute two different operations:
18
• read, denoted as r: Reads the value of count. The value of count is not changed.
• write, denoted as w: Writes a new value to count. The value of count changes, it is incremented by one.
We also define the threads to equate the states of the counter equally. Which means that all threads have the same observation partition. The actual parti- tion is that the threads cannot differentiate whether count is 0, 1 or ∗. Which follows from the fact that the threads only gain information upon a r-action or w-action. The latter of which is destructive in the sense that the gathered information is novel. The win-condition for the game is to increment the count such that it equals 2. We also define that the game is lost if the threads enter the state of “certain race condition”.
0 1
∗ win
(r,r) (r
,r) (w, r)
(r, w)
(w,w) (r,w)
(w,r)
(w, w)
(r,r) (r,w)
(w, r) (w,w)
Figure 4.1: The Shared counter variable concurrent program modelled as a Multi-player Game with imperfect information. The formal definition for this game is: P := {0, 1}, V := {0, 1, ∗, win}, E := {r, w}, O0 = O1 :=
{[0, 1, ∗], [win]}.
4.2 Nested knowledge
The concurrent counter model was iterated three times, which yields three lev- els of nested knowledge. Since we are interested in modelling the distributed knowledge of each Player, we will focus this section on the second and third iteration of the model.
Figure 4.2: The second MKBSC-iteration of the shared counter model in Fig- ure 4.1. Higher resolution image is found in the Appendix, on page 36.
”start”
{*,1}
{0,1}
{0,1} {0,1}
{*,1}
{*,1}
{*,1}
{0,1}
{0,1} {0,1}
{*,1}
{*,1} {*}
(r,w)
(r,r)
Figure 4.3: The nested knowledge to degree 2 in the shared counter game for the action sequence: (r, w), (r, r).
The second iteration of the counter game is noted in Figure 4.2. The knowl- edge for the different Players in the state score = 1 has been displayed as the knowledge tree in Figure 4.3, in order to aid analysis. Since the game is defined as being won if the score = 2, it implies that any singular write operations made by the Players at score = 1 wins the game. We note from Figure 4.3 that this strategy can be synthesised from the knowledge under the assumption that the Players play “safe” (i.e. not risk arriving in a uncertain state). The strategy synthesis is derived from the following reasoning:
Action 1, (r,w):
Player 0: I know that the score is not uncertain. Player 1 either knows this as well, or it might be that they have written to the counter and thus think that it is uncertain or 1.
Player 1: I know that the score is not 0. Player 0 either knows this as well, or it might be that they have read from the counter and thus think that it is 0 or 1.
Action 2, (r,r):
Player 0: I read the counter again. My knowledge is the same.
Player 1: I know that the score is not 0. Now, Player 0 either knows this as well, or it might be that they have read from the counter and thus think that it is 0 or 1. However, it is also possible that Player 0 performed the same action sequence as me, “w-r“. In that case they know for sure that the counter is uncertainty, since the double write caused uncertain and then read from the counter to check the score.
The strategy that can be synthesised follows from the knowledge that Player 0 knows for sure that the state is not uncertain, and that Player 1 knows that there is a possibility that Player 0 knows for certain that the score is uncertain. This means that the strategy, if the Players would play safe, is that Player 1 does not perform any further write operations. There is no limitation on which op- erations Player 0 can perform, since any read-action does not change the state of the score and any write-action that Player 0 performs (if Player 1 is prohib- ited to write) will win the game. The synthesised strategy is also presented in Table 4.1.
Order Knowledge State Action
1 {{0-0}, {0-0}} (r,w)
2 {{10-*1,10-10},
{10-*1,*1-*1}}
(r,r)
3 {{10-*1,10-10},
{10-*1,*1-*1,*-*1}}
(w,r)
Table 4.1: A winning strategy that the Players can follow (from the game in Figure 4.1), synthesised by the second level nested knowledge of Figure 4.2.
Results: Shared memory prob- lem
In the world of concurrency, one of the goals is to use multiple different pro- cesses simultaneously in order to minimise latency from the User’s perspec- tive. Given two or more processes that are working side-by-side, sharing some memory, how can we guarantee that a program is executed in a correct way?
Note that “correct” in this regard refers to the program being executed in a way that you would expect the program to be executed, if it were being executed by a single thread.
5.1 Deterministic
5.1.1 Game model
In this report we also want to investigate whether or not we can model “mem- ory sharing“ as a game. The game that we define is as follows: Given a number of threads n, and a winning state. Is there a way to guarantee that the winning state is reached? More specifically, a state is composed of m number of regis- ters, each being able to hold a value of 0 or 1. The winning state specifies what number should be contained in each register. In the starting state, the registers can contain any of the possible values.
23
As a game, we model each of the threads as a Player. All Players will make an action at the same time, resulting in a new state. The actions that are legal for a Player to make are:
• Do nothing, denoted as -1.
• Toggle the value of a register, denoted as t. i.e. Change the value of a register from 0 to 1 or vice versa. Note that the Player does not get to know what the value was changed to. The value of a register will be toggled if at least one Player chooses to toggle that register. If two Players choose to toggle the register, this will have the same effect as only one Player toggling it.
• Set the value of a register to 0, denoted as 0. If another Player chooses to toggle the same register at the same time that a Player sets the value to 0, this will have the same effect as toggling that register.
The values of the registers are not known from the start, i.e. they cannot be assumed to have a certain value. It is the job of the processes to co-operate in such a way that they reach the winning state. The Players have reached the winning state if all Players choose to act with “do nothing” in a state where the registers all contain the correct value.
0 1
lose win
(-1, 0),
(0, -1),
(0, 0)
(-1, t), (0, t), (t, -1), (t, 0), (t, t)
(-1, 0), (-1, t), (0, -1), (0, 0), (0, t), (t, -1), (t, 0), (t, t)
(-1,-1) (-1,-1)
Figure 5.1: The Shared register concurrent program modelled as a Multi- player Game with imperfect information. The formal definition for this game is: P = {0, 1}, V := {0, 1, lose, win}, E := {−1, 0, t}, O0 = O1 :=
{[0, 1, lose], [win]}.
5.1.2 Nested knowledge
In the first case we examined what happened when we have two Players and one register. This is the simplest case. Later on we will discuss what happens if we add either more registers or more Players. The winning state in this case will be to set the register’s value to 1, when it starts at 0. As per definition, the Players only know what the win-condition is, and not what the initial state is.
Figure 5.2: The shared register game modelled using the MKBSC-tool.
Higher resolution image can be found in the Appendix, on page 37.
After 3 iterations of MKBSC, the graph shown in Figure 5.3 is isomorphic with the graph that is generated in the second iteration. This gives 2 levels of nested knowledge about the game.
Figure 5.3: The shared register game modelled using the MKBSC-tool, it- erated until isomorphism. Higher resolution image can be found in the Ap- pendix, on page 38.
In the graph shown in Figure 5.3, many states that are predecessors of the winning state for some action e. However, due to the definition on the game the same action e in these particular states could also result in a loss. This can be seen in Figure 5.3, for states that have an outgoing edge labelled (−1, −1).
In such states it is therefore quite risky for the Players to decide to make the
“do nothing“ action since they are risking a loss. However, there are three nodes in Figure 5.3 each with the following knowledge respectively:
A ={{1 − 10, 1 − 1}, {10 − 1, 1 − 1}}
B ={{10 − 1, 10 − 10}, {10 − 1, 1 − 1}}
C ={{1 − 10, 1 − 1}, {10 − 10, 1 − 10}}
In all of these states, at least one of the Players are unable to distinguish the state from exactly one other state. However, all three of these states can not lead to the “lose” state by making the “do nothing” action. This means that the Players are guaranteed to win if they make the “do nothing” action in any one of these states.
Following this reasoning, one winning strategy is presented in Table ??.
Strategy synthesis
Using the three states mentioned earlier referred to as A, B and C, we are able to show that both players know that the "do nothing" action is the best. From the knowledge that the Players have, we know the following:
• Player 0 knows that states A and C will both reach the winning state if they take the “do nothing“ action.
• Player 1 knows that states A and B will both reach the winning state if they take the “do nothing“ action.
Since this is the case, both Players know that state A will lead to a win if the players play optimally and therefore, they will be able to assure themselves a win if they reach this state. Using reasoning like this, one is able to construct a strategy that builds upon the knowledge that you have for certain states.
This methodology shows how one is able to construct a winning strategy for a game if there exists such a strategy. Here we have only done this for a single state, but the same reasoning could be applied to the rest of the game graph in order to establish as much of a strategy as possible.
5.2 Non-Deterministic
In the definition of the game defined in Section 5.1, the game is completely deterministic. However, there may be concurrent systems where there is some uncertainty. In this section we will investigate a variation of the game which is not completely deterministic.
5.2.1 Game model
The rules of the game are similar to the above game. There will be n threads (Players) and m registers. Each action consists of each Player making a choice of which register to alter the value of or the Players can choose to do nothing.
When altering the value of a state, a Player can either set the value of the register to 0, or they can toggle the value of the state.
So far all the aspects of this game are identical to the previously mentioned game. We infer the aspect of nature by giving the system a bit of uncertainty as to what happens when different Players want to affect the same register. If one Player wants to set the value of a register to 0, while another Player wants to toggle the value of the register, this can either result in the register getting
a value of 0 (if toggling is done first), or 1 (if setting the register to 0 is done first).
The game graph for this game (with two Players and one register) is shown in Figure 5.4. Once again, the states for the game are the starting state, winning state and losing state as well as the “0” and “1” states that show what value is contained in the register. From each of the states “0” and “1”, the actions (t, 0) and (0, t) have two resulting states. They can result in either of the two states
“0” or “1” and this is determined by the nature component of the game. The win-condition of this game is that all Players decide to make the “do nothing”
action when the register has a value of 1.
Figure 5.4: Game graph for the shared memory game when the nature com- ponent is introduced. Higher resolution image can be found in the Appendix, on page 39.
5.2.2 Nested knowledge
For simplicity, we modelled the game using two Players and a single register.
Again the game was modelled using the MKBSC tool, and after two iterations the graph reached isomorphism with the first iteration. This means that we were not able to extract as much information about the game as in the previous two examples.
Figure 5.5 shows the iterated version of the game. Each state contains informa- tion about what each Player knows the state of the game could be. In Figure 5.5
there are four states, only one of which is not the start, losing or winning state.
In that particular state, all Players know that the state of the game is one of
“0” or “1”. However, neither Player knows which of the two states the game is currently in since they are unable to distinguish between them. Even if they make an action, the Players are still unsure about what the next state of the game will be. Thus, there seems to not exist any underlying winning memo- ryless strategy, since the Players have no way to know the current state of the game.
Figure 5.5: The shared register game with nature modelled using the MKBSC- tool, iterated until isomorphism.
Discussion
From the examples of the programs we defined, we were successfully able to model them as games. However, the relevance of our results in the field of systemic knowledge is debatable. Since all modelled games were overly simplified versions of concurrent computer programs, the application of our results could be redundant. Further, for the only game where we introduced a bit of uncertainty (non-determinism), we were unable to withdraw any knowl- edge from the game using our methods. This begs the questions whether a different approach might have been more suitable for our modelling.
When we modelled the games as being completely deterministic, we were able to collect a substantial amount of data from the graphs that were generated us- ing the MKBSC tool. We were able to extract each Player’s knowledge about the current state of each game by analysing the resulting MKBSC-iterations.
The models of the games that we came up with were very trivial to beat for a human, and as such we needed to make sure we did not include any of our own bias when looking at the graphs generated by the MKBSC tool. Instead, we solely looked at the given information in each node and only made obser- vations from the possible transitions in the graph itself. For the deterministic games we were able to show that a winning strategy could be synthesised.
We showed how strategy synthesis could be done for specific states of the graphs generated by the MKBSC tool. However, these are not necessarily the only strategies that could result in a guaranteed win. There are perhaps other possible winning strategies but they might not be possible to derive from the knowledge of each Player. This was an interesting result, since it shows that there is a limit to the knowledge of the Players, in order to synthesise a winning
30
strategy. Further, our games were simple to the extent that coming up with a winning strategy was completely trivial. As such, it would be interesting to investigate how we could find these trivial strategies with a program rather than by analysing the graphs manually.
The simplicity of the games was a large discussion part during our research
— how do we make the games more realistic? We looked into what would happen if we increased the size of the games in order to outline the limitations of our models. We discussed the possibility of using a shared memory game with two players and two registers (instead of one). However, iterating this game model using the MKBSC tool provided a graph that contained 53 states and approximately 1000 edges. This proved to be too much for us to be able to analyse, and we can therefore only give some thoughts as to what properties this graph contains.
We believe that if we were to be able to look at the graph in greater detail, we would find that there are some states where the “do nothing” move can be made without risking a loss. Similar to the results from the shared memory game with a single register, Player 0 can probably not distinguish this state from certain other states, and neither can Player 1. Therefore, if you wanted to synthesise a strategy, it would be very tricky. However, we believe that it is possible that there exists at least one state where all players know that they can safely make the “do nothing” move without risking a loss. If all players know this fact for the same state, then there exists at least one state where the players have a winning strategy. From there, one would be able to synthesise a complete strategy by building upon this.
Conclusion
For each of the deterministic games that we modelled, we were able to gather a lot of information about the knowledge of the Players for the states that were possible for the game. We explained how we could use the graph to gener- ate a strategy for a subset of the nodes in the graphs and this could then be done for the rest of the graph as well. However, for the game which was non- deterministic, we were unable to retrieve any knowledge about what the Play- ers knew about the current game state. We conclude from this gathering of knowledge, that it is possible to investigate concurrent computer programs by modelling them as games.
7.1 Future work
Increasing the complexity of the scenarios analysed in this paper is something that is left for future work. In this paper the scenarios modelled were both small and simple. Both of these aspects could be changed to get a better analysis of concurrent computer programs. This could be done by either adding more Players to our games, or by adding more complexity to the games in order to simulate a real world scenario more closely. Additionally, a tool for strategy synthesis is something that is of interest when analysing games such as those discussed in this report. Such a tool would make it much easier to analyse the graphs generated by the MKBSC tool.
32
[1] Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau. Operating Systems: Three Easy Pieces. 1.00. Arpaci-Dusseau Books, Aug. 2018.
Chap. 26, pp. 1–13.
[2] Dietmar Berwanger. “Graph games with perfect information”. In: (2012).
url: http://www.lsv.fr/~dwb/graph-games-pi.pdf.
[3] Erik Handberg and Lara Rostami. “Epistemic Structures for Strategic Reasoning in Multi-Player Games”. In: (2019). doi: urn:nbn:se:
kth:diva-255156.
[4] Edvin Lundberg. “Collaboration in Multi-agent Games : Synthesis of Finite-state Strategies in Games of Imperfect Information”. In: (2017).
doi: urn:nbn:se:kth:diva-231026.
[5] August Jacobsson and Helmer Nylén. “Investigation of a Knowledge- Based Subset Construction for Multi-Player Games of Imperfect Infor- mation”. In: (2018). doi: urn:nbn:se:kth:diva-231026. url:
https://github.com/helmernylen/mkbsc.
[6] Krishnendu Chatterjee et al. “Algorithms for Omega-Regular Games with Imperfect Information”. In: Logical Methods in Computer Science Volume 3, Issue 3 (July 2007). doi: 10.2168/LMCS-3(3:4)2007.
url: https://lmcs.episciences.org/1094.
[7] Dilian Gurov and Valentin Goranko. KTH Technical Report. Mar. 2020.
[8] Joseph Y. Halpern and Yoram Moses. “Knowledge and common knowl- edge in a distributed environment”. In: CoRR cs.DC/0006009 (2000).
url: https://arxiv.org/abs/cs/0006009.
[9] Joseph Y. Halpern and Yoram Moses. “Knowledge and Common Knowl- edge in a Distributed Environment”. In: Proceedings of the Third An- nual ACM Symposium on Principles of Distributed Computing. PODC
’84. Vancouver, British Columbia, Canada: Association for Comput- ing Machinery, 1984, pp. 50–61. isbn: 0897911431. doi: 10.1145/
33
800222.806735. url: https://doi.org/10.1145/800222.
806735.
[10] Joseph Y. Halpern and Ronald Fagin. “Modelling Knowledge and Ac- tion in Distributed Systems”. In: Distributed Comput. 3.4 (1989), pp. 159–
177. doi: 10 . 1007 / BF01784885. url: https : / / doi . org / 10.1007/BF01784885.
[11] Gil Neiger and Sam Toueg. “Simulating Synchronized Clocks and Com- mon Knowledge in Distributed Systems”. In: J. ACM 40.2 (Apr. 1993), pp. 334–367. issn: 0004-5411. doi: 10 . 1145 / 151261 . 151267.
url: https://doi.org/10.1145/151261.151267.
[12] Ronald Fagin et al. “Knowledge-based programs”. In: Distributed Com- puting 10.4 (1997), pp. 199–225. issn: 1432-0452. doi: 10 . 1007 /
s004460050038. url: https://doi.org/10.1007/s004460050038.
Higher resolution images of the iterated Games.
35
Figure 7.1: High resolution image of Figure 4.2.
Figure 7.2: High resolution image of Figure 5.2.
Figure 7.3: High resolution image of Figure 5.3.
Figure 7.4: High resolution image of Figure 28.
www.kth.se
