Bug 1764 - can't compile without pthread
can't compile without pthread
Status: PATCH PENDING
Product: ns-3
Classification: Unclassified
Component: core
pre-release
PC Linux
: P5 normal
Assigned To: Peter Barnes
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-21 12:34 EDT by Tom Henderson
Modified: 2016-03-03 12:59 EST (History)
5 users (show)

See Also:


Attachments
Minimal SystemMutex, CriticalSection and SystemThread (3.94 KB, patch)
2015-11-12 00:46 EST, Peter Barnes
Details | Diff
Minimal SystemMutex, CriticalSection and SystemThread, rev2 (3.95 KB, patch)
2015-12-07 19:38 EST, Peter Barnes
Details | Diff
Rev 3 (4.59 KB, patch)
2015-12-08 09:46 EST, Tommaso Pecorella
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Henderson 2013-09-21 12:34:05 EDT
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.
Comment 1 Gustavo J. A. M. Carneiro 2013-10-13 13:31:09 EDT
I pushed a patch to add a --disable-pthread option to waf, to make testing for this problem easier.
Comment 2 Peter Barnes 2015-11-12 00:46:03 EST
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.
Comment 3 Peter Barnes 2015-11-12 00:46:55 EST
That should be "thread-safe"
Comment 4 Peter Barnes 2015-12-07 19:38:00 EST
Created attachment 2202 [details]
Minimal SystemMutex, CriticalSection and SystemThread, rev2

Slightly revised patch
Comment 5 Peter Barnes 2015-12-07 19:54:36 EST
Last call
Comment 6 Tommaso Pecorella 2015-12-08 09:23:57 EST
(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).
Comment 7 Tommaso Pecorella 2015-12-08 09:46:31 EST
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)
Comment 8 Tom Henderson 2015-12-08 18:17:26 EST
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.
Comment 9 Tommaso Pecorella 2015-12-08 20:14:39 EST
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.
Comment 10 Peter Barnes 2016-01-25 15:37:38 EST
Revert to Patch Pending based on comments and needed followup.
Comment 11 Alexander Krotov 2016-03-03 04:36:57 EST
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
Comment 12 Peter Barnes 2016-03-03 12:59:39 EST
@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.