1.3.1   Evaluation of your code

Here are some criteria that will be taken into account for the evaluation of your source code:

• Homogeneous and reasonable indentation and spacing (paragraphs, empty lines, spaces between words).
• Your code is as simple as possible, but not simpler.
• The code is clear, easy to read.
• Your code is robust and well tested. It rather displays error messages complaining about non-treated corner cases than it produces run-time crashes (for instance, unhandled exceptions).
• You use comments to explain your code. You are strongly adviced to structure your code in paragraphs, and introduce every paragraph with a one-line comment.

2.7.1   The lock statement

Syntax:

lock (obj)
{
   // ...
}

• The obj object needs to an instance / static field if the objects protected from mutual exclusion are instace / static fields
• The lock statement internally uses monitors

See the C# reference for more information.

2.7.2   Monitors (locking)

• The Monitor class is a static class, that is, all methods are static
• See the Remarks section for the Monitor class.

There are four important operations:

System.Threading.Monitor.Enter (obj);
System.Threading.Monitor.Exit (obj);
System.Threading.Monitor.Wait (obj);
System.Threading.Monitor.Pulse (obj);

Enter and Exit lock and unlock threads calling these functions with the same object, like if the object was a semaphore or a mutex in the Phtreads library.

Wait and Pulse make possible that one thread that had acquired the monitor temporarily releases it, allowing another thread to acquire it. When that second thread acquires the monitor and calls Pulse, the first thread is scheduled to re-acquire the monitor, which may happen as soon as the second thread releases the monitor (when it calls Exit). Calls tu Pulse do not accumulate, that is, they are not remembered. If a thread calls Pulse and no thread is Wait-ing, the call is lost, and next time a thread calls Wait it may wait forever.

Exercises: ThreadExercises.cs, exercise 4.

2.7.3   Wait Handles (signaling and locking)

• Conceptual overview here
• All signaling primitives (EventWaitHandle, AutoResetEvent, Mutex...) inherit from the class WaitHandle !!
• Encapsulates Win32 synchronization handle
• Can be less portable and less efficient in terms of resource requirements than monitors/locks
• It is abstract, so it cannot be instantiated

Important methods:

System.Threading.WaitHandle.WaitOne ()
System.Threading.WaitHandle.WaitAll (WaitHandle [])
System.Threading.WaitHandle.WaitAny (WaitHandle [])

Derived classes differ in thread affinity (who can signal/release the wait handle, the thread that got it, or anyone?); mutexes have thread affinity, others have not

2.7.4   EventWaitHandle, AutoResetEvent, ManualResetEvent (signaling, but also locking)

All the three classes inherit from WaitHandle. We focus on EventWaitHandle, as the behaviour of AutoResetEvent and ManualResetEvent can be explained in terms of EventWaitHandle.

We can create an EventWaitHandle as follows:

bool            init = either true or false
EventResetMode  mode = either EventResetMode.AutoReset or EventResetMode.ManualReset

h = new EventWaitHandle (init, mode);

The object h is like a traffic semaphore, it can be red or green. It is initialized to false (red) or true (green). It works in two possible modes:

• AutoReset: Each car that crosses the semaphore (a thread calling WaitOne), turns the semaphore to red
• ManualReset: Whenever the semaphore is green, every car (thread) can cross freely (WaitOne does not block). If you want to stop cars, you need to manually turn the semaphore red (call the method Reset)

The methods of the class work as follows:

• Method Set turns the semaphore to green
• Method Reset turns the semaphore to red
• Method WaitOne lets the thread go if the semaphore is green, and blocks if it is red

AutoResetEvent and ManualResetEvent are classes deriving from EventWaitHandle. They behave like EventWaitHandle when it is initialized passing the associated value to the second parameter of the constructor.

More on auto-reset and manual-reset wait handles.

Exercises: ThreadExercises.cs, exercises 7 and 8.

2.7.5   CountdownEvent (signaling)

Consider the following code:

CountdownEvent cde = new CountdownEvent (12)

• It creates a CountdownEvent
• This is an object that behaves like a traffic semaphore with two integer variables associated to it:
  • the CurrentCount, it will act as a countdown counter, and
  • the InitialCount, the 12 passed to the constructor.
• The value of InitialCount can only be modified on the constructor
• You can modify the value of CurrentCount with
  • Signal(), decrements by 1
  • AddCount(), increments by 1
  • Reset(), sets it to the value of InitialCount
• A CountdownEvent has a WaitHandle associated to it, as well.
• When CurrentCount is 0, it sets the handle, that is, the semaphore becomes green.
• Otherwise the handle is closed (semaphore red)
• To block until the CurrentCount becomes 0, call the instance method Wait()
• If the handle is set (the CurrentCount is 0), calling Signal or AddCount will raise an exception. You can only call Reset.

2.7.6   Other Synchronization Primitives

• The Interlocked class, for atomic reading and writing shared variables (see Remarks section)
• Lightweight Synchronization Types
• Spin locks

3.1.1   The Client Side

• We need to establish the connection
• Beware that the static Dns.Resolve method, from System.Net.Dns is obsolete. Rather use GetHostEntry
• Then we can send or receive data synchronously through it

3.1.2   The Server Side

• We first bind and listen to an IP address and port
• We then accept incoming connections using the Accept method, which returns a new instance of the Socket class, this one associated with the new connecting client

While the client usually only establishes one connection at a time, the server needs to deal with potentially several ones. As in probably any other language you know, we have a select function for checking the status of several threads and blocking until we need to do some work.

The static method Socket.Select takes three lists of (references to) Socket instances and can block until there is something to read (first list), something to write (second list) or an error was reported (third list). A call to Select will return when at least one socket is ready to do work with it, which we can check with the Poll method of the Socket class.

If a socket is a listening socket, i.e., it is being used to accept new clients, place it in the reading list. If a client has arrived, and Accept will return immediately with its associated Socket, then the Poll method will return true when invoked with the SelectMode.SelectRead switch.

• Example 1: SimpleTcpClient.cs, illustrating how to create a client socket and receiving data form it.

3.1.3   UDP Sockets

• The client do not need to call Connect, it can rather send data using the SendTo and ReceiveFrom methods from the Socket class, which allow to directly provide the destination address
• If, however, it calls Connect on a UDP socket, incoming packages from a different IP address and port will be discarded.
• They client may also want to Bind the socket to an specific local IP and port before sending data
• As for the server, there is no need to call Listen (as you are not accepting connections), just create the socket and bind it to a local IP and port

Exercises: Client.cs, exercise 9; Server.cs, exercises 11, 12.

• Solution: ex9.cs.
• Solution: ex11.cs.