Circuitry for tristating the address and data outputs of a processor to
prevent a deadlock condition when the processor and another bus master is
accessing a shared resource. The processor is located on a local bus and
the other bus master is located on a PCI bus. Bi-directional tristate
buffers are placed between the address and data output pins of the
processor and the address and data portions of the first bus. If the
processor is requesting a local-bus-to-PCI-bus cycle, and the PCI bus
master is asserting a request for a local bus shared resource, the
processor address and data output pins are tristated by the tristate
buffers to allow the PCI bus master cycle to proceed. After the PCI bus
master cycle completes, the tristate buffers are reenabled to allow the
processor cycle to complete.

Answered by jaivir , an ibibo Master, at 7:58 PM on July 30, 2008

When multi-transaction mode is in effect across multiple DBEnvironments with multiple applications accessing the same DBEnvironments at the same time, it is possible that a deadlock that cannot be detected by ALLBASE/SQL could occur. This is known as an undetectable deadlock. In addition, when multi-transaction mode is used with multiple connections to the same DBEnvironment, an infinite wait can occur. To avoid these situations, be sure your timeout values are set to a value other than NONE. (Note that NONE is the default when no timeout value is specified at DBEnvironment creation time.)
Undetectable Deadlock Prevention

Suppose your application is simultaneously connected to two DBEnvironments in multi-transaction mode. At the same time, another user's application is connected to the same DBEnvironments. At some point as these applications execute, each one has an active transaction waiting for access to data locked by another transaction in the other application. It is a classic deadlock, and since the data being waited for spans more than one DBEnvironment, ALLBASE/SQL cannot detect this deadlock. The two databases will wait "forever" unless you have set a TIMEOUT value other than NONE for one or both of the application connections.
Infinite Wait Prevention

An application running in multi-transaction mode with multiple active transactions accessing data in the same DBEnvironment can encounter undetectable wait conditions. For instance, the first of two such transactions could be holding locks that cannot be released until the transaction is commited. And the second transaction could require the same locks in order to complete. The second transaction is waiting for the first to commit work, and the first transaction is waiting for the second to return control so that it can commit. Since both transactions are part of the same process, ALLBASE/SQL cannot detect this situation. Unless timeouts are set for at least one of these transactions, they could wait infinitely.

It may not be possible to predict an undetectable wait. Even when the transactions involved are accessing different tables, the physical proximity of system catalog data could mean that locks held by transaction one are required by transaction two. This is particularly true in relation to DDL statements (including the UPDATE STATISTICS statement, even though it is allowed in DML only mode) and dynamic space expansion.

To prevent an infinite wait, be sure to set appropriate timeout values and test for the occurrence of a timeout.

Answered by Sharad Singh , an ibibo Master, at 2:01 PM on July 30, 2008

Deadlock prevention is the process of making it logically impossible for one of the 4 deadlock conditions to hold:

1. Relaxing mutual exclusion requires making all relevant resources sharable. Some resources can be made sharable. There are generally some resources that cannot be spooled - semaphores, for example. Removing mutual exclusion is not always an option.

2. Relaxing Hold and Wait requires processes to acquire all their needed resources at once. To acquire new resources in such a system requires a process to relinquish all the processes it holds and try to reacquire all the resources it needs atomically. Reasonable systems can be programmed this way, but in practice it's almost never done.

3. Relxaing non-preemptability for resources other than the CPU is very non intuitive. The idea that a program might lose a lock at any time and have to reacquire it is very counterintuitive. Other than very specialized cases, relaxing non-preemptability is almost never done.

4. And finally, The most common method of preventing deadlock is to prevent the circular wait. A simple way to do this, when possible, is to order the resources and always acquire them in order. Because a process can't be waiting on a lower numbered process while holding a higher numbered one, a cycle is impossible.

For more details, refer to:

www.isi.edu/~faber/cs402/notes/ lecture9.html

Answered by A.R. , an ibibo Master, at 12:31 PM on July 30, 2008

well mohan anand,Deadlocks can be prevented by ensuring that at least one of the following four conditions occur:

* Removing the mutual exclusion condition means that no process may have exclusive access to a resource. This proves impossible for resources that cannot be spooled, and even with spooled resources deadlock could still occur. Algorithms that avoid mutual exclusion are called non-blocking synchronization algorithms.
* The "hold and wait" conditions may be removed by requiring processes to request all the resources they will need before starting up (or before embarking upon a particular set of operations); this advance knowledge is frequently difficult to satisfy and, in any case, is an inefficient use of resources. Another way is to require processes to release all their resources before requesting all the resources they will need. This too is often impractical. (Such algorithms, such as serializing tokens, are known as the all-or-none algorithms.)
* A "no preemption" (lockout) condition may also be difficult or impossible to avoid as a process has to be able to have a resource for a certain amount of time, or the processing outcome may be inconsistent or thrashing may occur. However, inability to enforce preemption may interfere with a priority algorithm. (Note: Preemption of a "locked out" resource generally implies a rollback, and is to be avoided, since it is very costly in overhead.) Algorithms that allow preemption include lock-free and wait-free algorithms and optimistic concurrency control.
* The circular wait condition: Algorithms that avoid circular waits include "disable interrupts during critical sections" , and "use a hierarchy to determine a partial ordering of resources" (where no obvious hierarchy exists, even the memory address of resources has been used to determine ordering) and Dijkstra's solution.
en.wikipedia.org/wi ki/Deadlock - 40k

Answered by Debashis , an ibibo Master, at 11:01 AM on July 30, 2008

Circuitry for tristating the address and data outputs of a processor to prevent a deadlock condition when the processor and another bus master is accessing a shared resource. The processor is located on a local bus and the other bus master is located on a PCI bus. Bi-directional tristate buffers are placed between the address and data output pins of the processor and the address and data portions of the first bus. If the processor is requesting a local-bus-to-PCI-bus cycle, and the PCI bus master is asserting a request for a local bus shared resource, the processor address and data output pins are tristated by the tristate buffers to allow the PCI bus master cycle to proceed. After the PCI bus master cycle completes, the tristate buffers are reenabled to allow the processor cycle to complete.

Answered by msg4hk , an ibibo Master, at 10:59 AM on July 30, 2008

Well Mohan , Deadlocks can be prevented by ensuring that at least one of the following four conditions occur:

* Removing the mutual exclusion condition means that no process may have exclusive access to a resource. This proves impossible for resources that cannot be spooled, and even with spooled resources deadlock could still occur. Algorithms that avoid mutual exclusion are called non-blocking synchronization algorithms.
* The "hold and wait" conditions may be removed by requiring processes to request all the resources they will need before starting up (or before embarking upon a particular set of operations); this advance knowledge is frequently difficult to satisfy and, in any case, is an inefficient use of resources. Another way is to require processes to release all their resources before requesting all the resources they will need. This too is often impractical. (Such algorithms, such as serializing tokens, are known as the all-or-none algorithms.)
* A "no preemption" (lockout) condition may also be difficult or impossible to avoid as a process has to be able to have a resource for a certain amount of time, or the processing outcome may be inconsistent or thrashing may occur. However, inability to enforce preemption may interfere with a priority algorithm. (Note: Preemption of a "locked out" resource generally implies a rollback, and is to be avoided, since it is very costly in overhead.) Algorithms that allow preemption include lock-free and wait-free algorithms and optimistic concurrency control.
* The circular wait condition: Algorithms that avoid circular waits include "disable interrupts during critical sections" , and "use a hierarchy to determine a partial ordering of resources" (where no obvious hierarchy exists, even the memory address of resources has been used to determine ordering) and Dijkstra's solution.

For more details , Please visit the source site :

http://en.wikipedia.org/wiki/D eadlock

Answered by Alok Gupta , an ibibo Guru, at 10:10 AM on July 30, 2008