This PR is a start on properly applying the GPLv2 license to the project code. Simply stating "GPLv2" at the bottom of the readme isn't enough to apply the license.

More remains to be done to apply the license correctly:

1. Add a copyright & license statement to the top of all project files (which are not already licensed by their own copyright holders)
2. Update the README with any additional licensed files which are used in the project (how about those images? what are their copyright/licensing?)

I will not be doing these 2 steps as I do not have the information necessary to complete them. It'll be up to the project founders to wrangle those.

Please see https://www.gnu.org/licenses/gpl-howto.html for complete information on applying a GPL license to a project.

Just what it says. Try running through Thread 0 a few times, Mutex will never unlock.

Also, on the right, the main if(){} enters mutex2 twice, but never exits.

If GitHub finds a CONTRIBUTORS file it will display a notice on PR forms to direct people to it before they submit their pull request. This helps prevent people from doing things like, say, sending a PR on master instead of devel. :-)

Jacques PERE-LAPERNE reported in my G+ thread:

For information, on my screen (1920 * 1080) the display is not correct for the toll tip

Screenshot at https://plus.google.com/u/0/photos/107251726787076664082/albums/6351652714871320289/6351652713502488546

• System.Collections.Generic.Queue hyperlinks don't work as they contain the inner type
• non-MSDN hyperlinks open in the same window as they miss target='_blank'
• "Peterson Algorithm" -> "Peterson's Algorithm" and hyperlink

These were from my investigation to see if I can make a Delphi version for the http://entwickler-konferenz.de early next week. It's going to be a challenge as this is my first real JavaScript/html code in a very long time (:

I'll keep the Delphi work in a separate branch, but will create a pull request for the other things.

Hi. I was playing a level and I had a plan and I accidentally won early. The victory text explains what happened, but I wanted to look at the code, too. So I clicked 'back to code'. Now the victory text is gone. (Forever?)

Just don't use modal popups. Append the victory text after the challenge text, above the code. Or below the code.

Just a suggestion! (Personally, I think the only uses for 'modal' dialogs are "an error has occurred and the application will now close" and "please log in". You know, situations where it can't possibly make sense to let the user poke around elsewhere. Otherwise, let the user poke around--don't lock their interface with a modal!)

Just a minor mistake in the tutorial's text that I felt obliged to fix. This "game" is fantastic. I'm new to concurrent programming. This is a great introduction.

Currently in the game the ManualResetEventSlim.Wait method blocks when the ManualResetEventSlim is set/signaled. It should block when it is reset/nonsignaled.

Also the description of the Manual Reset Event challenge contains the incorrect behavior: "The Wait() method blocks if the "reset event" is "signaled" (it starts out nonsignaled).".

The tooltip for the Wait method actually contains the correct behavior: "Atomic. Blocks until the ManualResetEventSlim's state is set to 'signaled'.".

Method description from msdn: "Blocks the current thread until the current ManualResetEventSlim is set." and "The caller of this method blocks indefinitely until the current instance is set. The caller will return immediately if the event is currently in a set state."

Not really in original scope and very high-effort, but adding just to keep track of this.

Some people requested editing the code. Arbitrary C# is probably unfeasible, but a limited subset might be doable.

See #50

The pull-request fixes these:

• System.Collections.Generic.Queue hyperlinks don't work as they contain the inner type
• non-MSDN hyperlinks open in the same window as they miss target='_blank'
• "Peterson Algorithm" -> "Peterson's Algorithm" and hyperlink

Sorry for the tab->space conversion in one of the files. No offence, but most files were already space indented anyway and my dev-toolchain is completely space based so that was easier for me.

In level "Condition Variables", there is a tool tip about winning the level for Monitor.exit() (which does not help, does it?) but not for queue.Dequeue() (which might help). I'll open a PR.

I made darkness and evil both 1 in first of loop, and entered lock twice (by releasing it in thread 1) in thread 0, then can never enter if in thread 1.

I think the ToString(...) function in variables.js already covers the below cases in ui.js so they can go:

            if (type.name.indexOf("Semaphore") != -1) {
                valueRepr = 'SemaphoreSlim [count: ' + variable.value + ']';
            }
            else if (type.name.indexOf("Queue") != -1) {
                valueRepr = 'Queue [element count: ' + variable.value + ']';
            }

http://deadlockempire.github.io/index.html?#H4-Barrier is the first level introducing Interlocked and Interlocked.Increment, but the class nor method are ever explained.

So it needs explanation and a link to https://msdn.microsoft.com/en-us/library/system.threading.interlocked and/or https://msdn.microsoft.com/en-us/library/system.threading.interlocked.increment

Level "A more complex thread"

The user should also win if Thread 1 waits for Thread 0 never releasing the mutex from TryEnter(mutex).

In that case, Thread 1 stalls and Thread 0 loops forever.

Related to #34 and #35

From my notes (in reStructuredText format):

+------------+--------------------------+
| Part       | A More Complex Thread
+============+==========================+
| Objective  | 1. follow guidance steps
|            | 2. break the code
+------------+--------------------------+
| Hint       | - have the threads deadlock each other
+------------+----------------------------------------------------+
| Steps      | Follow the guidance, then step threads:
|            |   1. Thread 1: step until the second ``Monitor.Exit(mutex);`` (now ``flag`` has value ``true``)
|            |   2. Thread 0: step until the second ``Monitor.Exit(mutex2);``
|            |   3. Thread 1: step until the first ``Monitor.Enter(mutex2);``
|            |   4. Thread 0: step until the first ``Monitor.Enter(mutex);``
|            |   5. Thread 1: step until the first ``Monitor.Enter(mutex);``
|            |   6. Thread 0: step until the first ``Monitor.Enter(mutex2);``
+------------+----------------------------------------------------+
| Learned    | - Concurrency issues sometime take multiple logic-flows to occur
|            | - The order of locking matters again
+------------+----------------------------------------------------+
| Note       | There is second issue that won't win the level, but nonetheless:
|            |   1. Thread 0: step until the first ``Monitor.Enter(mutex3);``
|            |   2. Thread 1: step until the first ``Monitor.Enter(mutex);``
|            | Since Thread 0 never exits ``mutex``, Thread 1 effectively hangs and Thread 0 loops.
+------------+----------------------------------------------------+