#115 issues with ATLAS 3.9.5 and win32 threads

[Sébastien Kunz-Jacques]

I tried to build ATLAS 3.9.5 with the default cygwin gcc, passing the option -Si nocygwin 1 to configure to prevent it to use cygwin posix threads, and ---shared to build dlls. It turns out this does not work, partly because of some ATLAS bugs:
- makes/Make.aux has some duplicate filenames in the 'obj' definition (ATL_{s,d,c,z}axpby.o), which yields duplicate object files in the final static libs and makes ld complain;
- include/atlas_threads.h activates windows threads if it sees the symbol ATL_OSWinNT, whereas it should read the symbol ATL_OS_WinNT defined by configure. As a result, windows threads are never used in that file;

When these two issues are corrected, there are places in the build process that attempt to build pthread-dependent code. Since pthread.h is unavailable with the above settings, errors occur and some parts of the build process are silently skipped (alternatively with a pthread-aware compiler such as a recent mingw, some pthread dependencies are pulled in the final libs which is what I would like to avoid). I worked around these problems in the non-pthread-friendly way described below:
- in tune\sysinfo\findNT.c, i removed line 42,
printf(fpout, " #include \"pthread.h\"\n");
that adds the pthread.h inclusion to the autogenerated file atlas_pthreads.h.
- in src\auxil\ATL_ptflushcache.c, I removed the pthread.h inclusion line 30 and rewrote ATL_ptFlushAreasByCL to let it use the atlas threads that redirect either to pthreads or win32 threads:

void ATL_ptFlushAreasByCL(FLSTRUCT *fp)
{
ATL_thread_t tp[ATL_NTHREADS];
int i;

for (i=0; i < ATL_NTHREADS; i++)
{
ATL_thread_start(tp+i, 0, ATL_ptCLF, fp);
}
ATL_FlushAreasByCL(fp); // should be redundant, do to be safe
for (i=0; i < ATL_NTHREADS; i++)
{
ATL_thread_join(tp + i);
}
}

- the ugliest part - in makes\Make.thr, I removed references to some pthread-specific targets: {,s,c,d,z}l3pt.
for instance
lib : lib.grd l3thr l3pt
becomes
lib : lib.grd l3thr
This is because at some point in the build, I noticed that some object files that were needed in the final lib where not being built because make dlib3 (in the folder src/threads/) was failing, because it was attempting to make dl3pt first, which is pthread-specific.

obviously these last steps are not correct fixes, however they enabled me to build dlls (with mingw gcc, see my request id 2159250) that work perfectly in visual studio, are faster than 3.9.4 and do not need the pthreads dll anymore. So I am still expecting a way to make all of this work out-of-the-box...

attached is the full diff file of the changes developped avove.

[Sébastien Kunz-Jacques]

patch to ATLAS 3.9.5

[R. Clint Whaley]

Hey,

Thanks for the detailed bug report! I am busy trying to catch up from beginning-of-semester stuff and an unexpected family emergency, but I will scope this in detail and fix for 3.9.6 ASAP. Sounds like you have a workaround for now . . .

Thanks,
Clint

[R. Clint Whaley]

Skj,

OK, I gave this a scope. The ptFlushAreasByCL was a true bug: I just forgot to rewrite it. I'm not sure your fix is correct, but it shouldn't matter, as I don't believe this routine is used by default during the install (and it is not part of the main library). The OS macro name was also a true bug.

The other things that you found are bugs for building a windows thread that does not include pthreads, but I actually meant to do them :) The reason is that my new threads implementation is still at such a state that I am constantly wanting to compare with the performance of ATLAS's original thread base (which is in ATLAS/src/pthreads), so I build both threading infrastructures, and have modified the timers to call them both, so I can constantly compare them head-to-head.

This is why your edit to the Make.thr is actually the correct one: the *only* reason I build *anything* from the pthreads/ directory is so I can compare old vs. new: getting rid of all targets that go to src/pthreads is precisely what you want to do if you aren't needing this . . .

Anyway, I am escalating this report to the bug tracker. Probably only the unintentional bugs will be fixed for 3.9.6 (I have already fixed them in the basefiles), but this report should provide a nice list for when I'm ready to have the default install not build posix threads on windows.

Thanks,
Clint

[R. Clint Whaley]

The ptflushcache problem was fixed as of 3.9.10 (rest of problems still there)