Dmitry Vostokov, 25th of March, 2010
http://www.dumpanalysis.org

Let’s recall the definition of a thread from the Dictionary of Debugging^[1]: A mapping T: t -> IP, where t is a discreet time arrow and IP is a memory space (Instruction Pointer). The following diagram depicts a thread in an equi-bipartitional virtual memory space comprised from user and kernel spaces:

The following diagram depicts 2 threads running in parallel:

We select a certain module that has a fixed address range interval:

Now, suppose the source code corresponding to modules has trace statements that write trace messages whenever a thread passes through them. We put black dots on a diagram to show these trace points:

We also label these points according to the time and color where the latter corresponds to thread ID (TID):

The full trace would look like this sequence of messages:

Y1
Y2
Y3
Y4
R5
Y6
R7
R8
Y9
Y10
Y11

If we restrict our messages to a particular thread we get these thread sequences:

Y1
Y2
Y3
Y4
Y6
Y9
Y10
Y11

and

R5
R7
R8

However, if we restrict our space to only Module A we get this sequence:

Y2
R5
R8

Such restrictions other than TID we call adjoint threads. We can also restrict to a particular source code file, function or even a trace message. Here is another illustration for a restriction by a process ID (PID) where black and red threads correspond to the same process:

We get this adjoint thread:

R5
B7
R8
R9
B10
B14

Adjoint threads were first introduced as an abstraction of particular software trace views^[2] in a Citrix CDF trace analysis tool^[3]. We can graphically view modules A and B as braid strings that “permeate the fabric of threads”. We also call this multibraiding because by changing trace message filters we can generate different adjoint threads:

[1]http://www.dumpanalysis.org/blog/index.php/category/dictionary-of-debugging/
[2]http://www.dumpanalysis.org/blog/index.php/2010/01/17/extending-multithreading-to-multibraiding-adjoint-threading/
[3]http://support.citrix.com/article/CTX122741