TBB Generic GCC / Cygwin Patch Questions

[montagftb]

I'm currently investigating the usage of the GCC atomic intrinsics with TBB, which are available for all GCC compilers >= 4.1. I do not believe the solution top be optimal, and in no way is intended to replace the compiler- and platform-specific work that provide a better TBB implementation. Nevertheless this work will give platforms not otherwise supported the ability to use TBB if they have a version of GCC that meets the requirements. One such platform is Cygwin, if you get a proper version of GCC installed. Kevin Farnham's blog posts on Cygwin support were very helpful, and I have tried to work around his patches which were sub-optimal (as he noted).

I've been able to use the tbb::atomic type with no perceived issues, and have been working to get the TBB make file operational, which it is to a degree. Midway through the makefile test suite I get the following error:

./test_task_scheduler_init.exe 1:4
terminate called after throwing an instance of 'std::runtime_error'
terminate called recursively
what(): pthread_attr_init: Device or resource busy
./test_task_scheduler_observer.exe 1:4
terminate called after throwing an instance of 'std::runtime_error'
what(): pthread_attr_init: Device or resource busy
./test_task_assertions.exe
done
./test_task.exe 1:4
terminate called after throwing an instance of 'std::runtime_error'
terminate called recursively
what(): pthread_attr_init: Device or resource busymake[1]: *** [test_tbb_plain] Aborted (core dumped)
make[1]: Leaving directory `/cygdrive/c/opensource/review/intel_tbb_libraries/build/cygwin_ia32_gcc_4.3.0_release'
make: [test] Error 2 (ignored)

I must confess I am no TBB expert, and really only use the library (currently) for the atomics code. All the same I am interested in getting my patches into the hands of the TBB developers, as I am pretty sure it won't take much more work to get generic GCC support working completely, and I know of at least one other person who is using TBB with Cygwin.

With all that said, here are my questions:
1) Does anyone know what the error above might be pointing to? Anyone know of a potential fix that is relatively low cost?
2) Would the TBB developers mind taking my patches as they are and trying to complete the work, given the work that has been done so far? If not, what would it take for TBB to adopt this code?

Thanks in advance!

[Vladimir_P_1234567890]

Hi!

What is package date? is it the latest stable package from Apr 08, 2008?

I've tried to build tests under cygwin by gcc 4.3 but get into linker errors with duplicated standard funcions in the tbb library and some of tests. it looks like that shared library is not natural way to work under cygwin. So it is good idea to make a contribution for cygwin support. Of course it would be good to have number_of_workers detection different from hardcoded value:)

the same for GCC atomic intrinsics, after code review we can consider adding the support to the library

upon contribution submit please to not forget to write a package name used as base for diff. some README would be great.

thanks,
Vladimir Polin,
TBB developer

[montagftb]

The changes are based off of the latest stable package of Apr 8, 2008.

I ran across those linker errors as well. It turns out gcc under cygwin expects shared libraries to have the ".dll" extension, as opposed to the UNIX-like ".so" extension. I have extensions to the makefile system in place that account for cygwin and make this change, and the linker errors were resolved.

I also added a command to the number_of_workers detection system that I believe works for cygwin, but am not 100% positive. Nevertheless, the code is able to query cygwin for system values, so if it doesn't currently work then finding a value that will should not be hard.

As I said in my previous post, the generic GCC support is not 100% ready yet. If you think the contribution is still worth turning over to TBB, please let me know. Otherwise I'd be happy to help out in getting the runtime test errors resolved with someone who has more TBB knowledge than myself.

Blessings,
Foster

[Vladimir_P_1234567890]

Very strange solution with .so->.dll renaming but it works:)

and I've managed to reproduce all issues you have reported. There are runtime errors with thread count more than 3. Moreover using different versions of cygwin runtime leads to getting different errors at the same places. it looks like there is some issues with posix threads support in cygwin.

Taking above thinks into account it would be possible to run tests etc by changing thread count from 1:4 to 1:2 or 1:3 in makefiles. For example you would need 2 threads only to run your application on dual core machine.

Regarding contribution. Definitely it _is not_ bad idea to make the contribution.:)

thanks,
Vladimir