Bugzilla – Bug 1764
can't compile without pthread
Last modified: 2016-03-03 12:59:39 UTC
We seem to have lost the ability to build without pthread somewhere along the way. This is making the Windows port more painful. How to reproduce: make this change: diff -r b5584cbb3ede src/core/wscript --- a/src/core/wscript Fri Sep 13 06:14:27 2013 -0700 +++ b/src/core/wscript Sat Sep 21 09:32:45 2013 -0700 @@ -72,7 +72,7 @@ conf.env['CCFLAGS_PTHREAD'] = '-pthread' conf.env['LINKFLAGS_PTHREAD'] = '-pthread' - conf.env['ENABLE_THREADING'] = have_pthread + conf.env['ENABLE_THREADING'] = False conf.report_optional_feature("Threading", "Threading Primitives", conf.env['ENABLE_THREADING'], and the build will fail: In file included from ./ns3/core-module.h:24:0, from ../src/internet/test/rtt-test.cc:19: ./ns3/default-simulator-impl.h:27:27: fatal error: system-thread.h: No such file or directory compilation terminated. Besides sorting this out, we probably need to expose a configuration option in waf to disable threading so we can test this configuration.
I pushed a patch to add a --disable-pthread option to waf, to make testing for this problem easier.
Created attachment 2182 [details] Minimal SystemMutex, CriticalSection and SystemThread This patch provides minimal implementations of SystemMutex, CriticalSection and SystemThread on systems without pthread support. These are required for the three-safe Schedule implementation in, e.g, DefaultSimulatorImplementation.
That should be "thread-safe"
Created attachment 2202 [details] Minimal SystemMutex, CriticalSection and SystemThread, rev2 Slightly revised patch
Last call
(In reply to Peter Barnes from comment #5) > Last call Sorry.... nope, something's not right. On a Mac, at least. The code in unix-system-mutex.cc needs to be conditionally compiled as well, otherwise it's a double definition. If you add a #ifdef, then there are missing symbols. Last but not least, HAVE_PTHREAD_H should be 1 (Mac does have Pthreads), but it's much like if it was undefined (at last from the error messages).
Created attachment 2203 [details] Rev 3 This should be slightly better. I added some #ifdef to the .cc and included core-config.h (that's why it wasn't detecting the pthread)
When I patch the "Rev 3" patch on ns-3-dev on a Mac OS X system, and call: ./waf configure --disable-pthread --enable-examples --enable-tests I get these build errors: In file included from src/core/bindings/ns3module.cc:1: src/core/bindings/ns3module.h:1048:31: error: no member named 'FdReader' in namespace 'ns3' ns3::SimpleRefCount< ns3::FdReader, ns3::empty, ns3::DefaultDeleter<ns3::FdReader> > *obj; ~~~~~^ src/core/bindings/ns3module.h:1048:88: error: expected member name or ';' after declaration specifiers ns3::SimpleRefCount< ns3::FdReader, ns3::empty, ns3::DefaultDeleter<ns3::FdReader> > *obj; ... tmp->Unref(); ^ src/core/bindings/ns3module.cc:37822:14: error: no type named 'FdReader' in namespace 'ns3' ns3::FdReader *tmp = self->obj; ~~~~~^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated.
On my Mac it works even with pthread forcefully disabled. the main difference is... I run without python bindings. perhaps they have to be rebuilt if we disable pthread ? It's just a guess, because the class signature is different (missing functions). (In reply to Tom Henderson from comment #8) > When I patch the "Rev 3" patch on ns-3-dev on a Mac OS X system, and call: > ./waf configure --disable-pthread --enable-examples --enable-tests > > I get these build errors: > > In file included from src/core/bindings/ns3module.cc:1: > src/core/bindings/ns3module.h:1048:31: error: no member named 'FdReader' in > namespace 'ns3' > ns3::SimpleRefCount< ns3::FdReader, ns3::empty, > ns3::DefaultDeleter<ns3::FdReader> > *obj; > ~~~~~^ > src/core/bindings/ns3module.h:1048:88: error: expected member name or ';' > after declaration specifiers > ns3::SimpleRefCount< ns3::FdReader, ns3::empty, > ns3::DefaultDeleter<ns3::FdReader> > *obj; > > ... > tmp->Unref(); > ^ > src/core/bindings/ns3module.cc:37822:14: error: no type named 'FdReader' in > namespace 'ns3' > ns3::FdReader *tmp = self->obj; > ~~~~~^ > fatal error: too many errors emitted, stopping now [-ferror-limit=] > 20 errors generated.
Revert to Patch Pending based on comments and needed followup.
Why not just remove pthreads from NS-3 completely? Quick 'grep' over NS-3 source code tree shows that nobody uses SystemMutex, CriticalSection etc to parallelize anything in NS-3. It is used in scheduler, but does not benifit anyone as is. I see the only reason to use pthreads or similar shared memory parallelization: to speed up computationally intensive algorithms *within* event processing, for example to keep up with clock in realtime simulation. So far there as no models in NS-3 that use pthreads this way. Parallelization across events requires more than just mutexes. Different scheduling algorithms should be employed. There is a work in progress that uses similar to NS-2 approach, but it uses MPI, not pthreads: https://www.nsnam.org/wiki/Parallel_Simulations
@Alexander: IIRC CriticalSection *is* used and required, to support Time::SetResolution in the face of Python. Also, there is a threaded SimulatorImpl which I'd like to revive at some point... I'd prefer to fix this without removing functionality...if I ever get some time to come back to this bug and test Tommaso's patch.