In this programming assignment you are tasked with preparing a C$++$ header

file named "Court.h$"$ implementing the Court class. This class will include

a constructor, enter, play and leave member methods. You have to implement all methods except play which will change with respect to test cases.

The details will be explained later in this section.

In our simulation the players will be represented by threads. These

threads will call enter, play and leave methods sequentially in this order. In these methods threads will use print statements to indicate their

state and you are tasked to provide synchronization between threads to make

these states obey the following rules:

When there are enough players for a match inside the court i$.$e$.,$ returned from the enter method, players must start the match.

$1$

There can not be more players in the court than the number required

for a match.

play method will represent a player passing some time in the court. If

there are not enough players for a match, we can interpret time spent

in this method like a free practice. When there are enough players and

a match starts, we can think of remaining time spent in this method

as playing a match. If a player is done playing $($returned form play

and called leave and a match has not started, it must leave without

playing in a match.

If there is a referee, players must not return from the leave method

until the referee announces that the game is over. Otherwise, players

can leave freely.

When a match finishes, the last player to leave must notify the waiting

players that are blocked in the enter method so that they can return

from this method and enter the court.

When there is a match, no one can enter the court before the match

finishes and all players and $($if exists$)$ the referee involved in the match

leaves the court.

We expect you to solve synchronization problems above using semaphores

and barriers only. When a thread is blocked due to a condition described

above, it should not busy$-$wait in a loop. Please, note that, if you use mutexes

instead of semaphores, busy$-$waiting loops will be inevitable. If you do so$,$

you might lose some points $($see Section $9).$ Basically, enter and leave

member methods should not contain any loops.

For other synchronization problems and critical sections that are not described above, you can use mutexes. For instance, if you want to ensure that

an increment operation on a shared counter is atomic, you can wrap this

operation with mutex lock and unlock methods.

For more information of these rules, how they can be achieved and for a

typical behaviour of a player thread please read the next section. You can

also find some sample runs at $10.$