For english below
Podczas laboratorium należy zbudować aplikację, w której dojdzie do synchronizacji wielu wątków. Aplikacja powinna pozwalać na uruchamianie tych wątków i obserwowanie ich stanów. Aplikacja powinna być parametryzowana (wyjaśnienie znajduje się dalej). Zakładamy, że aplikacja będzie pełnić rolę symulatora gry (z graficznym interfejsem), w której chodzi o obronę końcowych pól boiska przed nadlatującymi piłkami przez znajdujących się na tym boisku graczy dwóch przeciwnych drużyn. Niech boisko będzie planszą o zadanym rozmiarze, np. 9x10 lub więcej – przy czym liczba kolumn powinna być nieparzysta (rozmiar planszy to parametr). W drugiej i przedostatniej kolumnie planszy powinni poruszać się gracze, odpowiednio, jednej z dwóch drużyn. W każdej drużynie może być 2 lub więcej graczy (liczba graczy to parametr). Gracze poruszają się góra-dół, nie wchodząc na siebie. Każdy z graczy to osobny wątek. W środkowej kolumnie, w wylosowanych miejscach, pojawiają się piłki. Piłki poruszają się lewa-prawo, przy czym kierunek poruszania się piłki na samym początku jest losowy. Piłki dolatując do drugiej lub przedostatniej kolumny odbijają się od graczy i zmieniają kierunek ruchu, jeśli gracze tam są. Jeśli w przedostatniej lub ostatniej kolumnie pole jest puste, piłki dolatują do pierwszej lub ostatniej kolumny i tam kończą swój ruch. Każda piłka to osobny wątek. Na planszy nie może być więcej poruszających się piłek niż zadana liczba, minimum to 3, maksimum to liczba wierszy siatki (liczba piłek to parametr). Ponadto w jednym wierszu nie może pojawić się więcej niż jedna piłka. Piłki generowane są przez osobny wątek, który jest aktywny gdy liczba poruszających się piłek jest niższa od zadanego parametru (dezaktywuje się, gdy liczba poruszających się piłek zrówna się z tym parametrem, aktywuje się ponownie, gdy liczba poruszających się piłek spadnie poniżej tego parametru). W wierszach pierwszej i ostatniej kolumny powinny pojawiać się liczby mówiące o tym, ile piłek skończyło tam swój ruch. Im więcej piłek dotrze na daną stronę planszy, tym gorszy jest wynik broniącej jej drużyny. Gracze jednej drużyny powinni być wątkami realizującymi tę samą metodę run(). Piłki powinny być wątkami realizującymi tę samą metodę run(). Wątek generujący piłki powinien mieć własną metodę run(). Należy zapewnić synchronizację pomiędzy wątkami. Proszę zastanowić się, na czym polegać ma ta synchronizacja, co będzie zasobem współdzielonym itd. Ponadto w aplikacji powinna istnieć możliwość ustawiania prędkości przemieszczania się wątków graczy i piłek (aby dało się obserwować różnice w zachowaniach przy różnych parametrach symulacji). Chyba najprostszym sposobem wizualizacji tego, co się w laboratorium dzieje, jest użycie etykiet tekstowych jak na schemacie poniżej (liczby po bokach, tutaj na dwóch pozycjach, informują o liczbie piłek, które doleciały do końca danego wiersza; symbol # reprezentuje piłkę; literki reprezentują graczy). Oczywiście można zaimplementować inną graficzną reprezentację.
00a..._...a00
00...._....00
00..#._....00
00b..._...b00
05...._.#..00
00...._...c00
00....#....04
03c..._....00
00...._....00
00...._....02
Pozostałe szczegóły mają być zgodne z ustaleniami poczynionymi na początku zajęć.
During the lab, you should build an application in which multiple threads will synchronise. The application should allow you to run these threads and observe their states. The application should be parameterised (see below for an explanation). We assume that the application will act as a simulator of a game (with a graphical interface), in which the aim is to defend the final fields of a pitch against incoming balls by players of two opposing teams who are on that pitch. Let the pitch be a board of a given size, e.g. 9x10 or more - with an odd number of columns (board size is a parameter). In the second and penultimate column of the board should move the players of one of the two teams respectively. There can be 2 or more players in each team (the number of players is a parameter). Players move up and down, without stepping on each other. Each player is a separate thread. In the centre column, balls appear in drawn spaces. The balls move left-right, with the direction of ball movement at the very beginning being random. As the balls reach the second or penultimate column, they bounce off the players and change direction if the players are there. If the field is empty in the penultimate or last column, the balls arrive in the first or last column and end their movement there. Each ball is a separate thread. There cannot be more moving balls on the board than a given number, the minimum being 3, the maximum being the number of grid rows (the number of balls is a parameter). In addition, no more than one ball can appear in a single row. The balls are generated by a separate thread, which is active when the number of moving balls is lower than the set parameter (deactivates when the number of moving balls equals this parameter, activates again when the number of moving balls falls below this parameter). The rows of the first and last columns should show numbers indicating how many balls have finished their movement there. The more balls that reach a particular side of the board, the worse the score of the defending team. Players of one team should be threads executing the same run() method. The balls should be threads executing the same run() method. The thread generating the balls should have its own run() method. Synchronisation between threads should be ensured. Please consider what this synchronisation should consist of, what will be a shared resource, etc. In addition, it should be possible to set the speed of the player threads and ball threads in the application (so that it is possible to observe differences in behaviour with different simulation parameters). Probably the simplest way to visualise what is happening in the lab is to use text labels as in the diagram below (the numbers on the sides, here at two positions, indicate the number of balls that have made it to the end of a given row; the # symbol represents the ball; the letters represent the players). Of course, another graphical representation can be implemented.
00a..._...a00
00...._....00
00..#._....00
00b..._...b00
05...._.#..00
00...._...c00
00....#....04
03c..._....00
00...._....00
00...._....02
The remaining details are to be as agreed at the beginning of the class.