It Smack where technology meets......

Thursday, February 3, 2011

CWDN: Don ' t grow dreadlocks blocking code

Software application development, a so-called "blocking" is a situation where two or more tasks permanently block each other by each task having a lock on a resource (in system software), which the other tasks are also trying to lock. Think about two people who need two keys to tighten some bolts if each captures a key, then neither can finish its work - hence blockade ensures.


At the risk of is locked in this position and starts to grow dreadlocks on a deadblock - code consultant Alex Guryeva with an independent provider of software testing and quality management SQS (software quality systems), explains the big picture here.


 


Guryeva says that, because neither task in the above example can continue until a resource is available and resources can be released until a task continues, a deadlock state exists. The most common forms of locking that occur in the following systems:


• Database deadlocks
• Deadlocks in multithreaded (e.g., Java, c#, C++) applications


The following text is from the Guryeva analysis of the of this common coding conundrum...


Example a:


Database deadlock occurs when two users or sessions have locks on separate objects and each process is attempting to acquire a lock on the object that has other processes. SQL Server will identify the problem and ends the deadlock by automatically choosing one process and the abandonment of other processes, allowing other processes to continue. The aborted transaction is rolled back and an error message is sent to the user of the aborted process.


To avoid deadlocks, trying to develop the application so that it grabs locks at the last moment possible and frees them then at the time of the first. Also, do not allow any user during transactions input and try to gather before the start of the transaction. Keep the shortest possible transactions and use stored procedures or keeping transactions with a single batch [1].


Thinking about the analogy with the new tools: every person in need of the manoeuvre should ensure that their work is implemented so that they use their keys to the minimum time required and should avoid being distracted by other things (e.g. user input) using the keys.


Example b:


Multithreaded programs can execute several tasks at the same time. They allow the programmer to take advantage of multiple CPU machines (where they exist) from each processor to execute a different thread of control.


But writing multithreaded code that works properly every time is really difficult.


(Editor's note: it is worth remembering that Intel that advocates the use of parallel programming and concurrency in the structure of the code says that it is really not difficult once you get your state of mind wrapped around the concept.)


The most common reason for the cause of deadlocks in multithreaded applications is a sequence of incompatible lock. Deadlocked threads waiting for resources, which are in turn locked by another thread [2]. Indeed it is a kind of circular dependency, for example: X cannot complete its work until frees a resource, it cannot finish until z releases another resource, but z is waiting for a resource that x has already received - for everything which is deadlocked.


Here is a small piece of Java code, which can lead to an impasse.


Thread 1:
synchronized {}
synchronized (B) {}
}
}


Thread 2:
synchronized (B) {}
synchronized (C) {}
}
}
Thread 3:


synchronized (C) {}
synchronized {}
}
}


Usually, the simpler and more efficient to avoid blocking is to ensure that resources are always acquired in a well-defined order.


References:
[1] http://www.sql-server-performance.com/tips/deadlocks_p1.aspx
[2] Dawson Engler. RacerX: Detection, effective static race and deadlock conditions.


Author: Alex Guryeva


View the original article here

No comments:

Post a Comment