Showing results for 
Search instead for 
Did you mean: 


baker ebiabowei
Occasional Visitor


my name baker ebi,i want you to help me get a solution to the following question.
1. how to resolve critical section problem.
2. solution on critical section problem.
3.what is deadlock,how and why the resolve.
4. what is semaphores,where and how they are used.

please i need the solution as fast as possible,in other word 'ugently'.

Michael Tully
Honored Contributor

Re: solution

This should assist in explaining about semaphores:
Anyone for a Mutiny ?
Patrick Wallek
Honored Contributor

Re: solution

I am not sure what exactly you are asking with # 1 and # 2.

# 3 - A deadlock - maybe spinlock deadlock? - is almost ALWAYS a patch issue, or rather the lack of a very critical patch. A spinlock deadlock will panic (crash) your machine. In these cases HP can analyze the crash dump that the system generates and tell you what caused the spinlock deadlock and what patch or patches you need to install to resolve the issue.

# 4 - semaphores - There are many kernel parameters related to semaphores. Have a look at those parameters for more information. They are all the sem* parameters. Here is a link to the HP-UX 11iv1 Tunable Parameter Guide:

A. Clay Stephenson
Acclaimed Contributor

Re: solution

1) and 2) areimpossible to answer because you don't state ythe problem.

3) and 4) may be related.

It's probably easier to think of a semaphore as a file. Suppose that process A is not allowed to continue if the file "mysema4" exists and that process B is not allowed to continue
until the file "mysema4" exists. Normally these two processes create and remove the file co-operatively but suppose that process B hangs and never removes the file, process A is deadlocked and neither process will finish.

Semaphores are not actually files but are instead data structures in the kernel. The key idea is that the operations are atomic and that no process is allowed to alter a semaphore until the last operation is completed.

Without knowing what problem you are facing, it's not possible to help you much.
If it ain't broke, I can fix that.
R. Allan Hicks
Trusted Contributor

Re: solution

I'm guessing, but by critical section, do you mean a section of your code that either can't be interrupted or requires exclusive access to a resource?

I hope so, cause that's the questions I'm going to address.....

In many different kinds of processes, exclusive access to resources can be required. For example, you have two processes, one that writes to a file and another that reads from the same file. You don't want the writer writing while the reader is reading. Semiphore were developed to solve that type of problem.

In the simplest sense, a semiphore is a contract that is made among processes. Basically, it is agreed that in order to use a resource, the process must first lock a particular semiphore. There is nothing other than the user's coding that prevents the process from using the resource anyway. So, it is extremely important that all processes that uses the resource must lock the same semiphore.

The document that Michael directed you to will have more detail. A semiphore can be like a global variable that has two possible values, 0 and 1. The 0 state could indicate that the resourced is locked and 1 means that the device is available.

Why? because this is the agreement that all of the programmers made so that processes can cooperate with one another on using the shared resource. A process must start and create the semiphore.

Each semiphore has a unique key used to access the semiphore. To lock the resource, the process decrementsls the number. If the semiphore value is at 0, (dependingon the design), the system will block the processes The blocked process is suspended until the semiphore value returns to 1. When the locking process increments the semiphore value, it is signalling that resource is available.

When the semiphore returns to a 1 state, the system unblocks the process waiting for the resource which decrements the semiphore and the formerly blocked process, now has exclusive access to the resource. Any other processes that attempt to use the resource will be blocked.

A dead lock also known as a deadly embrace occurs when two or more processes attempt to use to or more resources.

For example, process 1 and process 2 require resources A and B. If process 1 locks the semiphore for resource A and process 2 locks the semiphore for resource B. If process 2 attempts to lock A and process 1 attempts to lock B, both processes will be blocked. This is deadly because unless one of the processes gives up the resource, they will remained blocked for all of time. This can occur if a process aborts without cleaning up the semiphore for the resource. Say your process did not respond to a kill signal by releasing the semiphore. The resource would be locked until you re-booted or you had a process that unlocked the semiphore.

Papers have no doubt been written on how to resolve deadly embrace issues. I'll offer you two short solutions.

a.) Always lock your resources in a particular order. All processes lock A, B, C, etc. That way if the first process to lock A, locks all processes out. The first process to lock the first sequence keeps the other processes from locking things that the other processes might try to lock.

b.) Set up a software interupt in the form of a timer. If the process blocks on a semiphore, the timer will wake the process up and the process can do exception processing generally in the form of release all resources and attempting to acquire them again.

In summary, a semiphore is like a global variable. Semiphores can be used by the system to coordinate activity and resources. If a semiphore has a certain value, it can cause a process that makes a call to alter the value suspend until another process resets the semiphore's value. In doing so, processes that can interfere with one another can be suspended during critical times to prevent them from interfering with one another.

-Hope this helped
"Only he who attempts the absurd is capable of achieving the impossible