Browse Prior Art Database

Debugging multithreading programs using thread assembly points Disclosure Number: IPCOM000144719D
Original Publication Date: 2007-Jan-05
Included in the Prior Art Database: 2007-Jan-05
Document File: 4 page(s) / 74K

Publishing Venue



Multithreading is a frequently used technology for improving program efficiency. However, debugging multithreaded programs can be really difficult and time consuming. The main reason is normally that threads interact with each other in a random way and problems do not always occur. In such cases, catching the right moment becomes crucial. This article proposes a mechanism for maximising thread interactions within a code segment suspected to be faulty to assist debugging. Unlike techniques published in [1,2,3], this proposal does not target specific types of thread interaction (i.e., through share variables) and is relatively easy to implement.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 47% of the total text.

Page 1 of 4

Debugging multithreading programs using thread assembly points

Disclosed is a programming technique which aims at maximising thread interactions within a code segment. This technique can be useful for debugging multithreaded programs. In production code, minimising the chances of unwanted interference from other threads is normally preferred in order to reduce the possibility of a program misbehaving. However, in a debug situation, exactly the opposite (i.e., maximising thread interactions) should be pursued.

    The proposed technique is a mechanism similar to a critical section that defines an assembly entry point and an assembly exit point of a code segment. These assembly points are initialised to gather a predetermined number of threads. Once entered, a thread is not allowed to leave and that applies to both the entry and exit assembly points. The point of having an entry assembly point is that thread interactions are more likely to happen. The point of having an exit assembly point is that execution environment is more likely to be preserved, making problem identification easier. One can step through an execution through such a controlled code section using a debugger, knowing that there are multiple threads in the section.

    The following is a simple Windows* C implementation of the idea, in the form of a head file. There is no deadlock prevention mechanism built in but deadlock can be easily prevented by introducing a timeout into the spin-locks used.


#include <Windows.h>

#define MAX_THREADS 100
typedef struct {
int maxThreads;
int noOfThreadsJoined;
int noOfThreadsLeaving;

bool canJoin, canEnter, canLeave;
bool switchedOn;
} ThreadAssemblyPoints;

inline bool initThreadAssemblyPoints(ThreadAssemblyPoints * assemply, int
assemplySize) { if (assemplySize>MAX_THREADS) {

return false ;


assemply->maxThreads = assemplySize;

assemply->noOfThreadsJoined = 0;

assemply->noOfThreadsLeaving = 0;


assemply->canJoin = true ;

assemply->canEnter = false ;

assemply->canLeave = false ;

assemply->switchedOn = false ;

return true ;


Page 2 of 4

inline void enterThreadAssembly(ThreadAssemblyPoints * assemply) {

if (!assemply->switchedOn) {

return ;



do {

// allow other threads to join;



// have we got enough threads now?

} while (!assemply->canJoin);

if (assemply->noOfThreadsJoined<assemply->maxThreads) {

// this thread can join the asembly

// register itself

assemply->threadIds[assemply->noOfThreadsJoined] = GetCurrentThreadId();

if (assemply->noOfThreadsJoined++==0) {

// this is the first thread joining this assembly.

// make it the master thread, which control the others.

do {

// allow ot...