Causing a deadlock to occur. They can be incredibly difficult to detect in situations where many mutexes/semaphors are used.

mutex A;
mutex B;

void thread1()
{

    do something...
	
    lock(A);
        lock(B);

            do something...

        unlock(B);
    unlock(A)
}

void thread2()
{
    do something...

    lock(B);
        lock(A);

            do something...

        unlock(A);
    unlock(B);
}

The above example is a trivialization of what could go wrong. If the following sequence of events were to happen, the above threads would go into a deadlock:

thread1: lock(A);
thread2: lock(B);    // no deadlock yet

thread2: lock(A);    // thread2 is blocked until A is unlocked

thread1: lock(B);    // thread1 is blocked until B is unlocked, but thread2 
                     // won't unlock B until A is unlocked, because thread1
                     // locked A. Thus, neither thread of execution can proceed

Deadlocks in more complicated cases can be difficult to detect. About the only way to prevent them is to design the code to never let it happen.

The above example could be fixed by replacing both mutexes with a single mutex, assuming there isn't an important reason for having the two mutexes.

Design strategies usually recommend minimizing the amount of code that needs the mutexes' protection, and isolating it. This is the basic idea behind monitors.

You need to access a shared variable in a multithreaded program, so you access the value directly, without any sort of locking. For example:

transferAmount = GetTransferAmount();
balance = GetBalanceFromDatabase();
 
if (transferAmount < 0) {
	printf("Bad Transfer Amount\n");
	exit(0);
}
newBalance = balance - transferAmount;
if ((balance - transferAmount) < 0) {
	printf("Insufficient Funds\n");
	newBalance = balance;
}
SendNewBalanceToDatabase(newBalance);
printf("Transfer of %f succeeded.\n",transferAmount);
NotifyUser("New balance: %f\n", newBalance);

In this example, we have no assurance that one instance of this user will get the correct transferAmount in either of the if-statements. Since, these statements control the flow of our program (and determine how much money is passed around) we could get situations where one instance transfers all of the money while another instance still has a full balance.

If a resource is shared between threads and each thread has a function that may change the resource state, you need a way to ensure that that resource will remain in the state expected by each state. This can be achieved by using synchronization primitives when available (such as 'synchronized' in Java), mutexes and atomic operations, or simply avoiding sharing resources across threads. Taking our example from above:

transferAmount = GetTransferAmount();

if( accountBusy )
	wait accountFree
else {
	signal accountBusy
	balance = GetBalanceFromDatabase();
 
	if (transferAmount < 0) {
		printf("Bad Transfer Amount\n");
		exit(0);
	}
	newBalance = balance - transferAmount;
	if ((balance - transferAmount) < 0) {
		printf("Insufficient Funds\n");
		newBalance = balance;
	}
	SendNewBalanceToDatabase(newBalance);
	signal accountFree
}
printf("Transfer of %f succeeded.\n",transferAmount);
NotifyUser("New balance: %f\n", newBalance);

Since we ensure that the shared resources can only be accessed by one thread at a time, we ensure that the state remains consistent between threads.

#!/bin/sh
echo "This is a test" > /tmp/test$$
# Someone can manipulate or alter the file between these calls
cat < /tmp/test$$

#!/bin/sh
echo "This is a test" | cat

struct stat mystat;
int myfd;

do checks on the file's properties      // the file could be swapped out/
                                        // modified in here

if(the checks are ok)
{

    do something with the file          // use the file
}

struct stat mystat;
int myfd;

do checks on the file's properties      // if someone swaps in their own 
                                        // file, it won't sneak in on the
                                        // program anymore

if(the checks are ok)
{
    do something with the file          // use the file
}   

This change will ensure that the file is the same file between the check and use. (It prevents someone from swapping in another file) It will not prevent someone changing the file's permissions to allow someone else to read/write the file between the check and use. 

Not using unsafe function calls at all in signal handlers is safest. Executing every use of a particular unsafe function atomically by blocking signals that call handlers that could cause them to be reentered may also be safe.