What I know is:

 - [`ReadLock`][2] and [`WriteLock`][1] affect each other somehow
 - `WriteLock` is just like *synchronized*
 - `ReadLock` seems cannot work alone

  [1]: https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.WriteLock.html
  [2]: https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.ReadLock.html

ReentrantReadWriteLock: what&#39;s the difference between ReadLock and WriteLock?

What is the difference between wait-die and wound-wait algorithms?

It seems that both of these deadlock prevention techniques are doing the same thing: A Rollback of older process.

What is the difference between the two? 

Please provide a suitable example to contrast the two algorithms.

What is the difference between &quot;wait-die&quot; and &quot;wound-wait&quot; deadlock prevention algorithms?

I am trying to simulate a deadlock on SQL Server.

    _|worker_id|salary|
    1|1        |100   |
    2|2        |300   |

Transaction 1 completed in 5 seconds.

    /* TRANSACTION 1*/
    Use dbmcw;

    DECLARE @sal1 INT, @sal2 int;

    BEGIN TRAN;

    SELECT @sal1 = salary
    FROM dbo.deadlock_demonstration WITH(UPDLOCK) 
    WHERE worker_id = 1;

    WAITFOR DELAY &#39;00:00:05.000&#39;;

    SELECT @sal2 = salary
    FROM dbo.deadlock_demonstration WITH(UPDLOCK)
    WHERE worker_id = 2;

    COMMIT TRAN;

Transaction 2 finished in 3 seconds.

    /* TRANSACTION 2*/
    Use dbmcw;

    DECLARE @sal1 INT, @sal2 int;

    BEGIN TRAN;

    SELECT @sal2 = salary
    FROM dbo.deadlock_demonstration WITH(UPDLOCK)
    WHERE worker_id = 2;

    SELECT @sal1 = salary
    FROM dbo.deadlock_demonstration WITH(UPDLOCK)
    WHERE worker_id = 1;

    COMMIT TRAN;

SQL Server is not giving any error. Deadlock did not occur. What should I change in order to simulate a deadlock?

How to simulate DEADLOCK on SQL Server?

I don&#39;t quite understand the difference between `Task.Wait` and `await`.

I have something similar to the following functions in a ASP.NET WebAPI service:

    public class TestController : ApiController
    {
    	public static async Task&lt;string&gt; Foo()
    	{
    		await Task.Delay(1).ConfigureAwait(false);
    		return &quot;&quot;;
    	}
    
    	public async static Task&lt;string&gt; Bar()
    	{
    		return await Foo();
    	}
    
    	public async static Task&lt;string&gt; Ros()
    	{
    		return await Bar();
    	}
    
    	// GET api/test
    	public IEnumerable&lt;string&gt; Get()
    	{
    		Task.WaitAll(Enumerable.Range(0, 10).Select(x =&gt; Ros()).ToArray());
    
    		return new string[] { &quot;value1&quot;, &quot;value2&quot; }; // This will never execute
    	}
    }

Where `Get` will deadlock.

What could cause this? Why doesn&#39;t this cause a problem when I use a blocking wait rather than `await Task.Delay`?

await vs Task.Wait - Deadlock?

POSIX allows mutexes to be recursive. That means the same thread can lock the same mutex twice and won&#39;t deadlock. Of course it also needs to unlock it twice, otherwise no other thread can obtain the mutex. Not all systems supporting pthreads also support recursive mutexes, but if they want to be [POSIX conform, they have to][1].

Other APIs (more high level APIs) also usually offer mutexes, often called Locks. Some systems/languages (e.g. Cocoa Objective-C) offer both, recursive and non recursive mutexes. Some languages also only offer one or the other one. E.g. in Java mutexes are always recursive (the same thread may twice &quot;synchronize&quot; on the same object). Depending on what other thread functionality they offer, not having recursive mutexes might be no problem, as they can easily be written yourself (I already implemented recursive mutexes myself on the basis of more simple mutex/condition operations).

What I don&#39;t really understand: What are non-recursive mutexes good for? Why would I want to have a thread deadlock if it locks the same mutex twice? Even high level languages that could avoid that (e.g. testing if this will deadlock and throwing an exception if it does) usually don&#39;t do that. They will let the thread deadlock instead.

Is this only for cases, where I accidentally lock it twice and only unlock it once and in case of a recursive mutex, it would be harder to find the problem, so instead I have it deadlock immediately to see where the incorrect lock appears? But couldn&#39;t I do the same with having a lock counter returned when unlocking and in a situation, where I&#39;m sure I released the last lock and the counter is not zero, I can throw an exception or log the problem? Or is there any other, more useful use-case of non recursive mutexes that I fail to see? Or is it maybe just performance, as a non-recursive mutex can be slightly faster than a recursive one? However, I tested this and the difference is really not that big.

  [1]: http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutexattr_gettype.html

Recursive Lock (Mutex) vs Non-Recursive Lock (Mutex)

When writing multi-threaded applications, one of the most common problems experienced are deadlocks.  

My questions to the community are:

1. What is a deadlock? 

2. How do you detect them? 

3. Do you handle them?  

4. And finally, how do you prevent them from occurring?

What is a deadlock?

I have the following four tests and the last one hangs when I run it. Why does this happen:

    [Test]
    public void CheckOnceResultTest()
    {
        Assert.IsTrue(CheckStatus().Result);
    }

    [Test]
    public async void CheckOnceAwaitTest()
    {
        Assert.IsTrue(await CheckStatus());
    }

    [Test]
    public async void CheckStatusTwiceAwaitTest()
    {
        Assert.IsTrue(await CheckStatus());
        Assert.IsTrue(await CheckStatus());
    }

    [Test]
    public async void CheckStatusTwiceResultTest()
    {
        Assert.IsTrue(CheckStatus().Result); // This hangs
        Assert.IsTrue(await CheckStatus());
    }

    private async Task&lt;bool&gt; CheckStatus()
    {
        var restClient = new RestClient(@&quot;https://api.test.nordnet.se/next/1&quot;);
        Task&lt;IRestResponse&lt;DummyServiceStatus&gt;&gt; restResponse = restClient.ExecuteTaskAsync&lt;DummyServiceStatus&gt;(new RestRequest(Method.GET));
        IRestResponse&lt;DummyServiceStatus&gt; response = await restResponse;
        return response.Data.SystemRunning;
    }

----------

I use this extension method for [restsharp RestClient][1]:

    public static class RestClientExt
    {
        public static Task&lt;IRestResponse&lt;T&gt;&gt; ExecuteTaskAsync&lt;T&gt;(this RestClient client, IRestRequest request) where T : new()
        {
            var tcs = new TaskCompletionSource&lt;IRestResponse&lt;T&gt;&gt;();
            RestRequestAsyncHandle asyncHandle = client.ExecuteAsync&lt;T&gt;(request, tcs.SetResult);
            return tcs.Task;
        }
    }

&lt;!-- --&gt;

    public class DummyServiceStatus
    {
        public string Message { get; set; }
        public bool ValidVersion { get; set; }
        public bool SystemRunning { get; set; }
        public bool SkipPhrase { get; set; }
        public long Timestamp { get; set; }
    }

Why does the last test hang?

  [1]: http://restsharp.org/


&#39;await&#39; works, but calling task.Result hangs/deadlocks

Will the following code result in a deadlock using C# on .NET?

     class MyClass
     {
        private object lockObj = new object();
    
        public void Foo()
        {
            lock(lockObj)
            { 
                 Bar();
            }
        }
    
        public void Bar()
        {
            lock(lockObj)
            { 
              // Do something 
            }
        }       
     }

Re-entrant locks in C#

I have a process with a Select which takes a long time to finish, on the order of 5 to 10 minutes. &lt;br/&gt;I am currently **not using** `NOLOCK` as a hint to the MS SQL database engine.&lt;br/&gt;At the same time we have another process doing updates and inserts into the same database and same tables.&lt;br/&gt; The first process has started, recently to end prematurely with a message 

&gt;SQLEXCEPTION: Transaction was deadlocked on lock resources with another process and has been chosen as the deadlock victim.

This first process is running at other sites in identical conditions but with smaller databases and thus the select statement in question takes a much shorter period of time (on the order of 30 seconds or so).     In these other sites, I don&#39;t get the deadlock message in these other sites.    I also did not get this message at the site that is having the problem initially, but, I assume, as the database has grown, I believe I must have crossed some threshold.      Here are my questions:

 1. Could the time it takes for a transaction to execute make the associated process more likely to be flagged as a deadlock victim. 
 2. If I execute the select with a NOLOCK hint, will this remove the problem?
 3. I suspect that a datetime field that is checked as part of the WHERE clause in the select statement is causing the slow lookup time.    Can I create an index based on this field?    Is it advisable?


Cause of a process being a deadlock victim

I am getting a C++ error with threading:

    terminate called without an active exception
    Aborted

Here is the code:

    #include &lt;queue&gt;
    #include &lt;thread&gt;
    #include &lt;mutex&gt;
    #include &lt;condition_variable&gt;
    
    template&lt;typename TYPE&gt;
    class blocking_stream
    {
    public:
    	blocking_stream(size_t max_buffer_size_)
    		:	max_buffer_size(max_buffer_size_)	
    	{
    	}
    	
    	//PUSH data into the buffer
    	blocking_stream &amp;operator&lt;&lt;(TYPE &amp;other)
    	{
    		std::unique_lock&lt;std::mutex&gt; mtx_lock(mtx);	
    		while(buffer.size()&gt;=max_buffer_size)
    			stop_if_full.wait(mtx_lock);
    
    		buffer.push(std::move(other));
    
    		mtx_lock.unlock();
    		stop_if_empty.notify_one();
    		return *this;
    	}
    	//POP data out of the buffer 
    	blocking_stream &amp;operator&gt;&gt;(TYPE &amp;other)
    	{
    		std::unique_lock&lt;std::mutex&gt; mtx_lock(mtx);
    		while(buffer.empty())
    			stop_if_empty.wait(mtx_lock);
    
    		other.swap(buffer.front());	
    		buffer.pop();
    
    		mtx_lock.unlock();
    		stop_if_full.notify_one();
    		return *this;
    	}
    	
    private:
    	size_t max_buffer_size;
    	std::queue&lt;TYPE&gt; buffer;
    	std::mutex mtx;
    	std::condition_variable stop_if_empty,
    							stop_if_full;
    	bool eof;	
    };

I modeled my code around this example:
http://www.justsoftwaresolutions.co.uk/threading/implementing-a-thread-safe-queue-using-condition-variables.html

What am I doing wrong and how do I fix the error?

C++ terminate called without an active exception

I came across some best practices for asynchronous programming using c#&#39;s `async`/`await` keywords (I&#39;m new to c# 5.0).

One of the advices given was the following:



**Stability: Know your synchronization contexts**

... 
Some synchronization contexts are non-reentrant and single-threaded. This means only one unit of work can be executed in the context at a given time. An example of this is the Windows UI thread or the ASP.NET request context.
In these single-threaded synchronization contexts, it’s easy to deadlock yourself. If you spawn off a task from a single-threaded context, then wait for that task in the context, your waiting code may be blocking the background task.

    public ActionResult ActionAsync()
    {
        // DEADLOCK: this blocks on the async task
        var data = GetDataAsync().Result;
    
        return View(data);
    }

    private async Task&lt;string&gt; GetDataAsync()
    {
        // a very simple async method
        var result = await MyWebService.GetDataAsync();
        return result.ToString();
    }

If I try to dissect it myself, the main thread spawns to a new one in `MyWebService.GetDataAsync();`, but since the main thread awaits there, it waits on the result in `GetDataAsync().Result`. Meanwhile, say the data is ready. Why doesn&#39;t the main thread continue it&#39;s continuation logic and returns a string result from `GetDataAsync()` ?

Can someone please explain me why there is a deadlock in the above example?
I&#39;m completely clueless about what the problem is ...

An async/await example that causes a deadlock

How could something equivalent to `lock` in C# be implemented in JavaScript?

So, to explain what I&#39;m thinking a simple use case is: 

User clicks button `B`.  `B` raises an onclick event.  If `B` is in `event-state` the event waits for `B` to be in `ready-state` before propagating.  If `B` is in `ready-state`, `B` is locked and is set to `event-state`, then the event propagates.  When the event&#39;s propagation is complete, `B` is set to `ready-state`.

I could see how something close to this could be done, simply by adding and removing the class `ready-state` from the button.  However, the problem is that a user can click a button twice in a row faster than the variable can be set, so this attempt at a lock will fail in some circumstances.

Does anyone know how to implement a lock that will not fail in JavaScript?

How to implement a lock in JavaScript

From a .NET 3.5 / C# app, I would like to catch `SqlException` but **only if it is caused by deadlocks** on a SQL Server 2008 instance. 

Typical error message is `Transaction (Process ID 58) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.`

Yet, it does not seem to be a documented [error code](http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlexception.aspx) for this exception.

Filtering exception against the presence of the *deadlock* keyword in their message seems a very ugly way to achieve this behavior. Does someone know the right way of doing this?

How to catch SqlException caused by deadlock?

I would like to explain threading deadlocks to newbies. I have seen many examples for deadlocks in the past, some using code and some using illustrations (like the famous [4 cars][1]). There are also classic easily-deadlocked problems like [The Dining Philosophers][2], but these may be too complex for a real newbie to fully grasp.

I&#39;m looking for the simplest code example to illustrate what deadlocks are. The example should:

 1. Relate to a &quot;real&quot; programming scenario that makes some sense
 2. Be very short, simple and straight forward

What do you recommend?

  [1]: http://www.cs.fsu.edu/~baker/cop5611.S03/graphics/F6-1.jpg
  [2]: http://en.wikipedia.org/wiki/Dining_philosophers_problem

Simple Deadlock Examples

I came across a strange situation where using a parallel stream with a lambda in a static initializer takes seemingly forever with no CPU utilization. Here&#39;s the code:

	class Deadlock {
		static {
			IntStream.range(0, 10000).parallel().map(i -&gt; i).count();
			System.out.println(&quot;done&quot;);
		}
		public static void main(final String[] args) {}
	}

This appears to be a minimum reproducing test case for this behavior. If I:

* put the block in the main method instead of a static initializer,
* remove parallelization, or
* remove the lambda,

the code instantly completes. Can anyone explain this behavior? Is it a bug or is this intended?

I am using OpenJDK version 1.8.0_66-internal.

Why does parallel stream with lambda in static initializer cause a deadlock?

I recently got this questions asked in an interview.

I answered that deadlock occurs if the interleaving goes wrong, but the interviewer insisted that a program that will always go into deadlock regardless of interleaving can be written . 

Can we write such a program ? Can you point me to some example program like that ?

Write a program that will surely go into deadlock

We&#39;re seeing some pernicious, but rare, deadlock conditions in the Stack Overflow SQL Server 2005 database.

I attached the profiler, set up a trace profile using [this excellent article on troubleshooting deadlocks](http://www.simple-talk.com/sql/learn-sql-server/how-to-track-down-deadlocks-using-sql-server-2005-profiler/), and captured a bunch of examples. The weird thing is that **the deadlocking write is *always* the same**:

    UPDATE [dbo].[Posts]
    SET [AnswerCount] = @p1, [LastActivityDate] = @p2, [LastActivityUserId] = @p3
    WHERE [Id] = @p0

The other deadlocking statement varies, but it&#39;s usually some kind of trivial, simple **read** of the posts table. This one always gets killed in the deadlock. Here&#39;s an example

    SELECT
    [t0].[Id], [t0].[PostTypeId], [t0].[Score], [t0].[Views], [t0].[AnswerCount], 
    [t0].[AcceptedAnswerId], [t0].[IsLocked], [t0].[IsLockedEdit], [t0].[ParentId], 
    [t0].[CurrentRevisionId], [t0].[FirstRevisionId], [t0].[LockedReason],
    [t0].[LastActivityDate], [t0].[LastActivityUserId]
    FROM [dbo].[Posts] AS [t0]
    WHERE [t0].[ParentId] = @p0

To be perfectly clear, we are not seeing write / write deadlocks, but read / write.

We have a mixture of LINQ and parameterized SQL queries at the moment. We have added `with (nolock)` to all the SQL queries. This may have helped some. We also had a single (very) poorly-written badge query that I fixed yesterday, which was taking upwards of 20 seconds to run every time, and was running every minute on top of that. I was hoping this was the source of some of the locking problems!

Unfortunately, I got another deadlock error about 2 hours ago. Same exact symptoms, same exact culprit write.

The truly strange thing is that the locking write SQL statement you see above is part of a very specific code path. It&#39;s *only* executed when a new answer is added to a question -- it updates the parent question with the new answer count and last date/user. This is, obviously, not that common relative to the massive number of reads we are doing! As far as I can tell, we&#39;re not doing huge numbers of writes anywhere in the app.

I realize that NOLOCK is sort of a giant hammer, but most of the queries we run here don&#39;t need to be that accurate. Will you care if your user profile is a few seconds out of date?

Using NOLOCK with Linq is a bit more difficult as [Scott Hanselman discusses here](http://www.hanselman.com/blog/GettingLINQToSQLAndLINQToEntitiesToUseNOLOCK.aspx).

We are flirting with the idea of using

    SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

on the base database context so that all our LINQ queries have this set. Without that, we&#39;d have to wrap every LINQ call we make (well, the simple reading ones, which is the vast majority of them) in a 3-4 line transaction code block, which is ugly.

I guess I&#39;m a little frustrated that trivial reads in SQL 2005 can deadlock on writes. I could see write/write deadlocks being a huge issue, but *reads?* We&#39;re not running a banking site here, we don&#39;t need perfect accuracy every time.

Ideas? Thoughts?

---

&gt; Are you instantiating a new LINQ to SQL DataContext object for every operation or are you perhaps sharing the same static context for all your calls?

Jeremy, we are sharing one static datacontext in the base Controller for the most part:

    private DBContext _db;
    /// &lt;summary&gt;
    /// Gets the DataContext to be used by a Request&#39;s controllers.
    /// &lt;/summary&gt;
    public DBContext DB
    {
        get
        {
            if (_db == null)
            {
                _db = new DBContext() { SessionName = GetType().Name };
                //_db.ExecuteCommand(&quot;SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED&quot;);
            }
            return _db;
        }
    }

Do you recommend we create a new context for every Controller, or per Page, or .. more often?

Diagnosing Deadlocks in SQL Server 2005

Probably between 25 and 50% of the times I build my solution, I see this:

&quot;[The operation you requested is taking longer than expected to complete. This dialog will close when the action completes.](http://i.imgur.com/UOtXUud.png)&quot;

I hate this window in ways I can&#39;t describe. It never resolves, the Cancel button is never enabled, and the only way to remedy it is to kill the devenv process and load up my entire solution again, knowing full well that I&#39;ve fixed nothing and I&#39;m equally liable to see the same thing when I attempt my build.

My solution is about 60 projects in total, which are mostly C# class libraries, with a few each of web applications, web services, and console applications. However, the problem persists even when building one slice of the codebase with the majority (50) of the projects unloaded.

My problem is that the output windows doesn&#39;t tell me anything at the point at which it freezes, and I don&#39;t know how else to determine the cause of this lockup. If I were to guess, I would assume that it&#39;s a deadlock in the filesystem or something, but I don&#39;t know how to go about proving this--much less how to prevent it.

What can I do to diagnose and eliminate this from my solution so that I never see it again? In general, how can I diagnose problems that occur during a build?

Visual Studio hangs constantly during build

I am working in a database where I load data in a raw table by a data loader. But today the data loader got stuck for unknown reasons. Then I stopped the data loader from windows task manager. But then I again tried to load data in the raw table but found its locked and I can&#39;t do any operation on it. I tried restarting SQL Server service but it was not resolved. And I have no permission to kill processes on this server. 

Below is the message showed by SQL Server. 

&gt; An exception occurred while executing a Transact-SQL statement or
&gt; batch. (Microsoft.SqlServer.ConnectionInfo)
&gt; 
&gt; Program Location:
&gt; 
&gt; at Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteNonQuery(String
&gt; sqlCommand, ExecutionTypes executionType)    
&gt; at Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteNonQuery(StringCollection
&gt; sqlCommands, ExecutionTypes executionType)    
&gt; at Microsoft.SqlServer.Management.Smo.ExecutionManager.ExecuteNonQuery(StringCollection
&gt; queries)    
&gt; at Microsoft.SqlServer.Management.Smo.SqlSmoObject.ExecuteNonQuery(StringCollection
&gt; queries, Boolean includeDbContext)    
&gt; at Microsoft.SqlServer.Management.Smo.NamedSmoObject.RenameImplWorker(String
&gt; newName)    
&gt; at Microsoft.SqlServer.Management.Smo.NamedSmoObject.RenameImpl(String
&gt; newName)
&gt; 
&gt; ===================================
&gt; 
&gt; Lock request time out period exceeded. Either the parameter @objname
&gt; is ambiguous or the claimed @objtype (OBJECT) is wrong. (.Net
&gt; SqlClient Data Provider)
&gt; 
&gt; ------------------------------   
&gt; Server Name: 162.44.25.59 
&gt; Error Number: 1222    
&gt; Severity: 16 State: 56     
&gt; Procedure: sp_rename Line Number: 282  

My SQL Server version is 2008 R2.  


How to solve SQL Server Error 1222 i.e Unlock a SQL Server table

I&#39;m running into a deadlock situation when calling [StackExchange.Redis][4].

I don&#39;t know exactly what is going on, which is very frustrating, and I would appreciate any input that could help resolve or workaround this problem.

-----
&gt;**In case you have this problem too and don&#39;t want to read all this;**
&gt;I suggest that you&#39;ll try setting `PreserveAsyncOrder` to `false`.
&gt;
&gt;     ConnectionMultiplexer connection = ...;
&gt;     connection.PreserveAsyncOrder = false;
&gt;
&gt;Doing so will probably resolve the kind of deadlock that this Q&amp;A is about and could also improve performance.

-----


### Our setup ###

* The code is run as either a Console application or as an Azure Worker Role. 
* It exposes a REST api using [HttpMessageHandler][1] so the entry point is async.
* Some parts of the code have thread affinity (is owned by, and must be run by, a single thread).
* Some parts of the code is async-only.
* We are doing the [*sync-over-async*][2] and [*async-over-sync*][3] anti-patterns. (mixing `await` and `Wait()`/`Result`).
* We&#39;re only using async methods when accessing Redis.
* We&#39;re using StackExchange.Redis 1.0.450 for .NET 4.5.

### Deadlock ###

When the application/service is started it runs normally for a while then all of a sudden (almost) all incoming requests stop functioning, they never produce a response. All those requests are deadlocked waiting for a call to Redis to complete.

Interestingly, once the deadlock occur, any call to Redis will hang but only if those calls are made from an incoming API request, which are run on the thread pool.

We are also making calls to Redis from low priority background threads, and these calls continue to function even after the deadlock occurred.

&lt;strike&gt;*It seems as if a deadlock will only occur when calling into Redis on a thread pool thread.*&lt;/strike&gt; I no longer think this is due to the fact that those calls are made on a thread pool thread. Rather, it seems like any async Redis call **without continuation, or with a *sync safe* continuation,** will continue to work even after the deadlock situation has occurred. (See *What I think happens* below)

### Related ###

* https://stackoverflow.com/questions/27235124/stackexchange-redis-deadlocking

  Deadlock caused by mixing `await` and `Task.Result` (sync-over-async, like we do). But our code is run without synchronization context so that doesn&#39;t apply here, right?

* https://stackoverflow.com/questions/24296325/how-to-safely-mix-sync-and-async-code

  Yes, we shouldn&#39;t be doing that. But we do, and we&#39;ll have to continue doing so for a while. Lots of code that needs to be migrated into the async world.

  Again, we don&#39;t have a synchronization context, so this should not be causing deadlocks, right?

  Setting `ConfigureAwait(false)` before any `await` has no effect on this.

* https://stackoverflow.com/questions/25567566/timeout-exception-after-async-commands-and-task-whenany-awaits-in-stackexchange

  This is the thread hijacking problem. What&#39;s the current situation on this? Could this be the problem here?

* https://stackoverflow.com/questions/27258984/stackexchange-redis-async-call-hangs/

  From Marc&#39;s answer:

  &gt; ...mixing Wait and await is not a good idea. In addition to deadlocks, this is &quot;sync over async&quot; - an anti-pattern.

  But he also says:

  &gt; SE.Redis bypasses sync-context internally (normal for library code), so it shouldn&#39;t have the deadlock

  So, from my understanding StackExchange.Redis should be agnostic to whether we&#39;re using the *sync-over-async* anti-pattern. It&#39;s just not recommended as it could be the cause of deadlocks in **other** code.

  In this case, however, as far as I can tell, the deadlock is really inside StackExchange.Redis. Please correct me if I&#39;m wrong.

### Debug findings ###

I&#39;ve found that the deadlock seems to have its source in `ProcessAsyncCompletionQueue` on [line 124 of `CompletionManager.cs`][5].

Snippet of that code:

	while (Interlocked.CompareExchange(ref activeAsyncWorkerThread, currentThread, 0) != 0)
	{
		// if we don&#39;t win the lock, check whether there is still work; if there is we
		// need to retry to prevent a nasty race condition
		lock(asyncCompletionQueue)
		{
			if (asyncCompletionQueue.Count == 0) return; // another thread drained it; can exit
		}
		Thread.Sleep(1);
	}

I&#39;ve found that during the deadlock; `activeAsyncWorkerThread` is one of our threads that is waiting for a Redis call to complete. (*our thread* = a thread pool thread running *our code*). So the loop above is deemed to continue forever.

Without knowing the details, this sure feels wrong; StackExchange.Redis is waiting for a thread that it thinks is the *active async worker thread* while it is in fact a thread that is quite the opposite of that.

I wonder if this is due to the *thread hijacking problem* (which I don&#39;t fully understand)?

### What to do? ###

The main two question I&#39;m trying to figure out:

 1. Could mixing `await` and `Wait()`/`Result` be the cause of deadlocks even when running without synchronization context?

 2. Are we running into a bug/limitation in StackExchange.Redis?

### A possible fix? ###

From my debug findings it seems as the problem is that:

    next.TryComplete(true);

...on [line 162 in `CompletionManager.cs`][6] could under some circumstances let the current thread (which is the *active async worker thread*) wander off and start processing other code, possibly causing a deadlock.

Without knowing the details and just thinking about this &quot;fact&quot;, then it would seem logical to temporarily release the *active async worker thread* during the `TryComplete` invocation.

I guess that something like this could work:

    // release the &quot;active thread lock&quot; while invoking the completion action
    Interlocked.CompareExchange(ref activeAsyncWorkerThread, 0, currentThread);

    try
    {
        next.TryComplete(true);
        Interlocked.Increment(ref completedAsync);
    }
    finally
    {
        // try to re-take the &quot;active thread lock&quot; again
        if (Interlocked.CompareExchange(ref activeAsyncWorkerThread, currentThread, 0) != 0)
        {
            break; // someone else took over
        }
    }

I guess my best hope is that [Marc Gravell][7] would read this and provide some feedback :-)

### No synchronization context = The default synchronization context

I&#39;ve written above that our code does not use a [synchronization context][9]. This is only partially true: The code is run as either a Console application or as an Azure Worker Role. In these environments [`SynchronizationContext.Current`][11] is `null`, which is why I wrote that we&#39;re running *without* synchronization context.

However, after reading [*It&#39;s All About the SynchronizationContext*][10] I&#39;ve learned that this is not really the case:

&gt; By convention, if a thread’s current SynchronizationContext is null, then it implicitly has a default SynchronizationContext.

The default synchronization context should not be the cause of deadlocks though, as UI-based (WinForms, WPF) synchronization context could - because it does not imply thread affinity.

### What I think happens ###

When a message is completed its completion source is checked for whether it is considered *sync safe*. If it is, the completion action is executed inline and everything is fine.

If it is not, the idea is to execute the completion action on a newly allocated thread pool thread. This too works just fine when `ConnectionMultiplexer.PreserveAsyncOrder` is `false`.

However, when `ConnectionMultiplexer.PreserveAsyncOrder` is `true` (the default value), then those thread pool threads will serialize their work using a *completion queue* and by ensuring that at most one of them is the *active async worker thread* at any time.

When a thread becomes the *active async worker thread* it will continue to be that until it have drained the *completion queue*.

The problem is that the completion action is *not sync safe* (from above), still it is executed on a thread that **must not be blocked** as that will prevent other *non sync safe* messages from being completed.

Notice that other messages that are being completed with a completion action that *is sync safe* will continue to work just fine, even though the *active async worker thread* is blocked.

My suggested &quot;fix&quot; (above) would not cause a deadlock in this way, it would however mess with the notion of *preserving async completion order*.

So maybe the conclusion to make here is that **it is not safe to mix `await` with `Result`/`Wait()` when `PreserveAsyncOrder` is `true`**, no matter whether we are running without synchronization context?

(*At least until we can use .NET 4.6 and the new [`TaskCreationOptions.RunContinuationsAsynchronously`][8], I suppose*)

[1]: https://msdn.microsoft.com/en-us/library/system.net.http.httpmessagehandler(v=vs.118).aspx

[2]: http://blogs.msdn.com/b/pfxteam/archive/2012/04/13/10293638.aspx

[3]: http://blogs.msdn.com/b/pfxteam/archive/2012/03/24/10287244.aspx

[4]: https://github.com/StackExchange/StackExchange.Redis

[5]: https://github.com/StackExchange/StackExchange.Redis/blob/master/StackExchange.Redis/StackExchange/Redis/CompletionManager.cs#L124

[6]: https://github.com/StackExchange/StackExchange.Redis/blob/master/StackExchange.Redis/StackExchange/Redis/CompletionManager.cs#L162

[7]: https://stackoverflow.com/users/23354/marc-gravell

[8]: https://msdn.microsoft.com/en-us/library/system.threading.tasks.taskcreationoptions(v=vs.110).aspx

[9]: https://msdn.microsoft.com/en-us/library/system.threading.synchronizationcontext(v=vs.110).aspx

[10]: https://msdn.microsoft.com/magazine/gg598924.aspx

[11]: https://msdn.microsoft.com/en-us/library/system.threading.synchronizationcontext.current(v=vs.110).aspx

Deadlock when accessing StackExchange.Redis

Can somebody please explain with examples (of code) what is the difference between **deadlock** and **livelock**?

What&#39;s the difference between deadlock and livelock?

What is the difference between a dead lock and a race around condition in programming terms?

Difference between racearound condition and deadlock

I have a block of code that runs within a TransactionScope and within this block of code I make several calls to the DB. Selects, Updates, Creates, and Deletes, the whole gamut. When I execute my delete I execute it using an extension method of the SqlCommand that will automatically resubmit the query if it deadlocks as this query could potentially hit a deadlock. 

I believe the problem occurs when a deadlock is hit and the function tries to resubmit the query. This is the error I receive: 

&gt;The transaction associated with the current connection has completed but has not been disposed. The transaction must be disposed before the connection can be used to execute SQL statements.

This is the simple code that executes the query (all of the code below executes within the using of the TransactionScope):

    using (sqlCommand.Connection = new SqlConnection(ConnectionStrings.App))
    {
    	sqlCommand.Connection.Open();
    	sqlCommand.ExecuteNonQueryWithDeadlockHandling();
    }

Here is the extension method that resubmits the deadlocked query:

    public static class SqlCommandExtender
    {
    	private const int DEADLOCK_ERROR = 1205;
    	private const int MAXIMUM_DEADLOCK_RETRIES = 5;
    	private const int SLEEP_INCREMENT = 100;
    
    	public static void ExecuteNonQueryWithDeadlockHandling(this SqlCommand sqlCommand)
    	{
    		int count = 0;
    		SqlException deadlockException = null;
    	
    		do
    		{
    			if (count &gt; 0) Thread.Sleep(count * SLEEP_INCREMENT);
    			deadlockException = ExecuteNonQuery(sqlCommand);
    			count++;
    		}
    		while (deadlockException != null &amp;&amp; count &lt; MAXIMUM_DEADLOCK_RETRIES);
    
    		if (deadlockException != null) throw deadlockException;
    	}
    
    	private static SqlException ExecuteNonQuery(SqlCommand sqlCommand)
    	{
    		try
    		{
    			sqlCommand.ExecuteNonQuery();
    		}
    		catch (SqlException exception)
    		{
    			if (exception.Number == DEADLOCK_ERROR) return exception;
    			throw;
    		}
    
    		return null;
    	}
    }

The error occurs on the line:

    sqlCommand.ExecuteNonQuery();

TransactionScope Prematurely Completed

How can I *programmatically* detect that a deadlock has occurred in a Java program?

Programmatic deadlock detection in java

When the Java application is hanging, you don&#39;t even know the use case that is leading to this and want to investigate, I understand that thread dumps can be useful.

But how can we easily derive useful data from the thread dumps to find where the problem is? The server application that I&#39;ve been working with produces very long thread dumps, because it is an EJB architecture and thread dumps contains many container threads that I&#39;m not sure I should be looking at (i.e. threads that are not running my application code, but JBoss&#39;s code). 

Yesterday I tried the [Thread Dump Analyzer][1] tool. The tool is definitely better than looking at the raw thread dumps in a text editor, because you can filter out threads that you&#39;re not interested in, see the thread list, click on a thread to see its details, compare thread dumps to find long running threads, etc.

But there&#39;s still too much data to analyse - almost 300 threads. I don&#39;t know of any criteria that I could use to filter out all the JBoss threads, in which I&#39;m not interested. I&#39;m not sure if I should be looking at threads that are currently in &quot;runnable&quot; state only or if &quot;waiting on condition&quot; and &quot;in Object.wait&quot; are also important.

What&#39;s the approach that you would normally follow and tools that you would in general use? 


  [1]: http://java.net/projects/tda

Thread Dump Analysis Tool / Method

I have a innoDB table which records online users. It gets updated on every page refresh by a user to keep track of which pages they are on and their last access date to the site. I then have a cron that runs every 15 minutes to DELETE old records.

I got a &#39;Deadlock found when trying to get lock; try restarting transaction&#39; for about 5 minutes last night and it appears to be when running INSERTs into this table. Can someone suggest how to avoid this error?

=== EDIT ===

Here are the queries that are running:

**First Visit to site:**

    INSERT INTO onlineusers SET
    ip = 123.456.789.123,
    datetime = now(),
    userid = 321,
    page = &#39;/thispage&#39;,
    area = &#39;thisarea&#39;,
    type = 3

**On each page refresh:**

    UPDATE onlineusers SET
    ips = 123.456.789.123,
    datetime = now(),
    userid = 321,
    page = &#39;/thispage&#39;,
    area = &#39;thisarea&#39;,
    type = 3
    WHERE id = 888

**Cron every 15 minutes:**

    DELETE FROM onlineusers WHERE datetime &lt;= now() - INTERVAL 900 SECOND

It then does some counts to log some stats (ie: members online, visitors online).


How to avoid MySQL &#39;Deadlock found when trying to get lock; try restarting transaction&#39;

Long time ago, I saved a sentence from a Java reference book: *&quot;Java has no mechanism to handle deadlock. it won&#39;t even know deadlock occurred.&quot; (Head First Java 2nd Edition, p.516)*

So, what is about it? Is there a way to catch deadlock case in Java? I mean, is there a way that our code understands a deadlock case occurred?

Deadlock detection in Java

Is it technically possible for a thread in Java to deadlock itself?

I was asked this at an interview a while back and responded that it wasn&#39;t possible but the interviewer told me that it is. Unfortunately I wasn&#39;t able to get his method on how to achieve this deadlock.

This got me thinking and the only situation that I can think of is where you can have this happen is where you have an RMI server process which contained a method that calls itself. The line of code that calls the method is placed in a synchronized block.

Is that even possible or was the interviewer incorrect?

The source code I was thinking about was along these lines (where testDeadlock is running in an RMI server process)

    public boolean testDeadlock () throws RemoteException {
    	synchronized (this) {
    		//Call testDeadlock via RMI	loopback			
    	}
    }

Is it possible for a thread to Deadlock itself?

Why does this code not cause a deadlock?

       private static readonly object a = new object();

... 

       lock(a)
       {
          lock(a)
          {
             ....
          }
       }



Why do nested locks not cause a deadlock?

&gt; **Possible Duplicate:**  
&gt; [Re-entrant locks in C#](https://stackoverflow.com/questions/391913/re-entrant-locks-in-c-sharp)  

&lt;!-- End of automatically inserted text --&gt;

If I write some code like this:

	class Program {
		static void Main(string[] args) {
			Foo();
			Console.ReadLine();
		}

		static void Foo() {
			lock(_lock) {
				Console.WriteLine(&quot;Foo&quot;);
				Bar();
			}
		}

		static void Bar() {
			lock(_lock) {
				Console.WriteLine(&quot;Bar&quot;);
			}
		}
		
		private static readonly object _lock = new object();
	}

I get as output:

    Foo
    Bar

I expected this to deadlock, because Foo acquires a lock, and then waits for Bar to acquire the lock.  But this doesn&#39;t happen.  

Does the locking mechanism simply allow this because the code is executed on the same thread?

All Deadlock Solutions on Gang of Coders

Total of 30 Deadlock Solutions

ReentrantReadWriteLock: what's the difference between ReadLock and WriteLock?

What is the difference between "wait-die" and "wound-wait" deadlock prevention algorithms?