[Nauty-list] Multithreading

[Brendan McKay]

Hi Matthew and Susanne,

This discussion is very interesting. Actually I was unaware of this
__thread facility and it seems like a good thing to incorporate
officially. My current idea is to have an option on "configure" that
tests if this feature is available and if so turns it on.  I think
leaving it off as default is probably good.

I notice gcc has an option -ftls-model that specifies different
ways of implementing thread-local variables.  Do you have any
experience of its effect?

I don't know of anyone who uses nauty in a strictly reetrant
fashion. If there are any applications, the __thread facility could
be used to fudge it: start an extra thread for the recursive calls.

Brendan.


* Matthew Skala <mskala at cs.umanitoba.ca> [120113 05:34]:
> On Thu, 12 Jan 2012, Susanne Niess wrote:
> > Could you please also send me the make file to apply the changes to the files
> > in nauty? I applied it to several of them by hand and then couldn't compile
> > them, so something must still be wrong. My includes are
> > #include "../nau/naututil.h"
> > #include "../nau/nauty.h"
> > #include "../nau/gtools.h"
> > and my compiling script contains
> > ../nau/nauty.o ../nau/nautil.o ../nau/naututil.o ../nau/naugraph.o
> > ../nau/nausparse.o ../nau/rng.o ../nau/gtools.o
> 
> Attached are a small Makefile and a modified version of mkts.  You will
> also need to change whatever other Makefile you're using so that it will
> link with, and depend on, files named tnauty.c instead of nauty.c,
> tnauty.o instead of nauty.o, and so on.  If you need more help, I'd
> suggest we take this discussion off-list, because it'll be primarily a
> question of getting your compiler to read the modified files rather than
> anything nauty-specific.
> 
> > asked back because I could not think of a possibility to run more than one
> > nauty in one thread at the same time (as nauty itself does not call itself
> 
> It's possible but tricky - the callback situation might be the most likely
> way it might happen, if you tried to define a user-defined refinement
> procedure or similar that itself invoked nauty.  I could imagine someone
> attempting that even if it might not be a good idea, and it would raise
> re-entrancy problems.
> -- 
> Matthew Skala
> Postdoctoral Fellow, University of Manitoba
> mskala at cs.umanitoba.ca

> #!/usr/bin/perl
> 
> $tlkw=shift;
> 
> print "/* DO NOT EDIT THIS FILE - it is automatically generated. */\n";
> 
> while (<>) {
>    s/(#include\s+"[^\"]*)nauty.h"/$1"tnauty.h"/g;
>    s/(#include\s+"[^\"]*)naututil.h"/$1"tnausparse.h"/g;
>    s/(#include\s+"[^\"]*)gtools.h"/$1"tgtools.h"/g;
>    
>    s/(static\s+)
>      (FILE|boolean|dispatchvec|graph|int|long|permutation|
>         set|short|shortish|size_t|statsblk|tcnode|type|unsigned)
>      (\s+[^(;,=]+[;,=])
>     /$1$tlkw\ $2$3/gx;
> 
>    print;
> }

> t%.h: %.h mkts
> 	./mkts '__thread' $< > $@
> 
> t%.c: %.c mkts
> 	./mkts '__thread' $< > $@
> 

> _______________________________________________
> Nauty-list mailing list
> Nauty-list at cs.anu.edu.au
> http://dcsmail.anu.edu.au/cgi-bin/mailman/listinfo/nauty-list