The Old Joel on Software Forum: Part 3 (of 5)

Multithreading

Hi,
I am developing a multithreading application which has 3 threads and a shared resource is there anyway to know which thread is accessing the shared resource.

saravanan
Monday, December 1, 2003

That depends on how you define "accessing the shared resource".

Do you actually mean "which thread holds the semaphore (or mutex or critical section or lock)?" That depends on the OS, language, and synchronization primitives you're using.

It would also help to know why you need to know. Is it just for monitoring/deadlock detection, or do you want to do different things depending on the thread id? If so, reconsider; that way lies madness.

Chris Tavares
Monday, December 1, 2003

this application is written using vc++ and the reason i want to know about is purely for montoring purpose where i am searching
an item in linked list which has about 50,000 entries. and my application is deadlocked.

saravanan
Monday, December 1, 2003

If it's just for monitoring purposes, write the thread ID to a shared location just after acquiring the resource.

Monday, December 1, 2003

You could implement the shared resource as an object that has methods for aquiring/releasing and checking the shared resource, and that object would have a property that holds the ID of the caller that currently holds the resource. The call would be something like this:

Done:=FALSE;
repeat
if SharedResource.isFree then begin
SharedResource.Aquire(Self.Handle);
SharedResource.DoThis;
SharedResource.DoThat;
SharedResource.Release(Self.Handle);
Done:=TRUE;
end;
until Done;
end;

It might not be sufficient to have these application implemented locks in a multithreaded environment. You may also use the OS specific syncronization primitives as the earlier poster stated.

Patrik
Monday, December 1, 2003

Use the GetCurrentThreadId windows API.

Frederik Slijkerman
Monday, December 1, 2003

One possibility is that you aren't releasing the resource every time you acquire it. The best way to avoid this is to create a Monitor class that acquires the resource in its constructor and releases it in its destructor. You can then use this class to keep track of who has ownership. I might look like this:

template<typename Resource>
class Monitor
{
Resource& m_resource;
Monitor(const Monitor&); // not implemented
Monitor& operator=(const Monitor&); // not implemented
public:
Monitor(Resource& res) : m_resource(res){/*acquire here, maybe with a calls to GetCurrentThreadId and OutputDebugString */}
~Monitor(){/*release here*/}
};

depending on the details of your situation, you might also need a bool m_acquired flag.

Brian
Monday, December 1, 2003

saravanan, I'm not going to write the code for you, but:

To answer to "is there any way to tell which thread is accessing" the resource is... kind of do it yourself. But don't base your implementation on testing anything. Just let the OS do the work for you.

One way to do this is to implement a "guard" procedure that only allows one thread at any time to access the resource.

Look at the API functions that manipulate the CRITICAL_SECTION data type. You'd have one static instance of CRITICAL_SECTION in your application, and two procedures: one to gain the lock of the CRITICAL_SECTION and thus permit the thread to manipulate the shared resource, and one procedure to release the lock. The second or third thread that tries to access the CRITICAL_SECTION will be suspended within your entry procedure.

The point is, you don't really need to know which thread has the lock. With proper design, whoever does will keep anyone else out.

Bored Bystander
Monday, December 1, 2003

You also probably don't need multithreading to search a linked list unless you're doing something really odd. Might want to back up and look at it again.

Jason McCullough
Monday, December 1, 2003

You might consider this article + tool for debugging of
critical section/locking problems.

http://msdn.microsoft.com/msdnmag/issues/03/12/CriticalSections/default.aspx

Michael Moser
Monday, December 1, 2003