C# – How to set a time limit for a game

• You do not need to use dedicated threads: a thread is an expensive object so it is generally better to use the thread pool since it will reuse threads to process your work items. Using a dedicated thread is a good idea if you need thread-local storage, thread identity, thread priorities, custom scheduling (picking work item from a stack or a priority queue rather than a queue), a higher priority than work items (if you have thousands of work items in the queue, a thread is likely to get a time slice earlier) or conversely if you want to leave the queue free for something else, etc.

• Enqueuing a work item on the thread pool is still a moderately expensive operation (above hundreds of nanoseconds). Besides the algorithm used to dynamically adjust the number of threads in the pool works best when each work item is not too long (let's say less than one millisecond). If your work items are longer than this or if they suffer a poor scalability (database or IO contention), you may want to limit the max number of threads in the pool.

• Some timers will enqueue their callbacks over the ThreadPool and some others on the UI. You need to check whether your timer will conflate with any other work you could have enqueued, especially long-running work items on the ThreadPool, and if it is important that your callbacks run before pending work items.

• Async/await are mostly necessary when the identity of the thread matters, typically for agents. For example the UI typically can only be manipulated from the UI thread (this is a thread affinity mechanism that serves as a synchronization pattern) and you often need to dispatch a task to a background thread from the UI thread then continue it later over the UI again. While on one hand your services look like agents, on the other hand it may be a design mistake as I just explained and anyway it does not seem like you need to dispatch continuations back to the service.

  However tasks are a nice abstraction to use and Parallel.Foreach, Task.Run and others will use the thread pool by default.

Edited the async/await section to take into account the comments below from Robert Harvey Edited to mention timers's callbacks.

There is much more involved in running a program than just the code within that program.

Any program that runs in a multi-process OS is under the control of the OS's scheduler, and the scheduler does maintain an explicit table saying what process is running, which ones are waiting to run when CPU cycles are available, and which are not even trying to run (sleeping). The scheduler typically assigns even-sized time slices to processes depending on their priority and their execution history. Ultimately, this loop is driven by hardware interrupts, usually generated by an oscillator on the main board.

Sleeping is always a feature that a programming language can support only because the run-time environment where it will be executed supports it. A normal program cannot suspend itself, it can only tell the scheduler how it would like to be treated - and the scheduler is by no means obliged or even always capable of satisfying that wish. Think of a laptop being closed and going into hibernation; the main board's oscillator keeps pulsing, but since the scheduler isn't running, no process can be running either no matter how high its priority is.