|
Bugzilla – Full Text Bug Listing |
| Summary: | can't compile without pthread | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Tom Henderson <tomh> |
| Component: | core | Assignee: | Peter Barnes <pdbarnes> |
| Status: | PATCH PENDING --- | ||
| Severity: | normal | CC: | gjcarneiro, krotov, ns-bugs, pdbarnes, tommaso.pecorella |
| Priority: | P5 | ||
| Version: | pre-release | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Attachments: |
Minimal SystemMutex, CriticalSection and SystemThread
Minimal SystemMutex, CriticalSection and SystemThread, rev2 Rev 3 |
||
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. |
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.