[Nauty-list] Multithreading

[Matthew Skala]

On Thu, 12 Jan 2012, Susanne Niess wrote:
> Thank you for your help! I use gcc and pthread and on one computer linux but
> on the other unix (or even old-aged solaris) - is this a problem? Have I

I would think that almost any environment that provides threads should
have some equivalent to __thread, but the exact syntax might be different
for different systems.  You'd have to check your own system's
documentation to figure out how to request thread-local variables and
change the directive accordingly.  But it's probably worth trying the gcc
syntax first and seeing if it works on your other system.  It may.

> understood correctly that I can still invoke nauty again and again in a
> thread, just not at the same time, running somehow parallel? I would not be

Right.  Given that you were asking about multithreading my assumption was
that you're familiar with the general background:  threads allow software
to split into several parts that run simultaneously, and software like
nauty can have trouble working in such an environment because different
threads may try to use the same variables at the same time.  They may also
try to use the same functions at the same time but that's not a problem
because functions are generally read-only; it's the static variables built
into the functions that make trouble.  The change I'm suggesting causes
all static variables to exist as multiple copies, with each thread having
its own separate copy.  The consequences are:

  * You can run nauty in several threads at the same time, because each
    thread uses its own set of variables.

  * You can run nauty repeatedly, starting it again after it finishes,
    many times in the same thread.  That was always the case, no change
    to the nauty code needed.

  * You should NOT attempt to start nauty again in the same thread while
    another call to nauty is still in progress.  This is the sort of thing
    that could happen as a result of calling it inside signal handlers,
    or attempting to run nauty recursively inside a callback called by
    nauty.  This is an unusual case and you would probably know if it were
    relevant to you.  In order to make this case work the code would need
    to be what's called "re-entrant," and more drastic changes than the
    one I'm suggesting would be needed to make it re-entrant.

Something else worth noting is that if it happens you have a multithreaded
program, but you know you will only call nauty in one of the threads, then
you don't need to change anything; standard nauty will work.  The only
need for special attention to thread-safety and re-entrancy issues with
nauty is if you have more than one copy of nauty running at the same time
in the same process.

> Unfortunately, I don't know Perl. Can I just use mkts like a bash script or do

If you have Perl installed, it should be possible to just make the file
executable and run it, much as you would with a bash script.  If your Perl
happens to be installed somewhere other than /usr/bin/perl, you might have
to change the pathname at the top of the script to say where Perl is.

> I hope the performance cost is not too too high, as I keep having
> huge runtimes.

I haven't tried to measure the cost of thread-local variables exactly, but
it hasn't seemed to make a noticeable difference in my own work.
Multithreading at all involves some amount of overhead, but if you know
that multithreading is what you want to do, you're presumably accepting it.
-- 
Matthew Skala
Postdoctoral Fellow, University of Manitoba
mskala at cs.umanitoba.ca