salut Benoît, your approach sounds reasonable to me. having all threads-related functionality in OpenThreads is the way to go. imho there is no good reason for maintaining another thread-wrapper in sg.
a quick scan shows following classes in sg: class SGThread class SGMutex class SGPthreadCond if they can all be safely replaced with corresponding OpenThread classes that would be fine. i agree with curt's comments, but i'd say: please take the time to carefully compare the code in sg and OpenThreads (like you did below). it is indeed easy to introduce subtle bugs with threading code. cheers, -till p.s. probably your headline was bad. i think you want to "replace sg thread classes with OpenThreads" (OpentThreads does use pthread on *nix) On Wednesday 30 April 2008, Benoît Laniel wrote: > > Perhaps you could begin by explaining the problem you are going to solve, > > and why your way is better. > > For windows version of fg, actually there are 2 solutions: > - no threads > - pthreads-win32 > > pthreads-win32 is, for me, a hack to ease the porting of *nix code to > win32 and may not always be efficient. > > However, in fg you seem to use openthreads. Since osg is needed for both > fg and sg, I thought you could use openthreads in sg too. > > So I started looking at the threads code in sg and noticed you use > pthread for only one thing : SGGuard. > > >From what I understood, the code > > static SGMutex mutex; > SGGuard<SGMutex> locker(mutex); > > does this : > > - SGMutex constructor : calls pthread_mutex_init() > - SGGuard constructor : calls SGMutex.lock() (which calls > pthread_mutex_lock()) > then > - SGGuard destructor : calls SGMutex.unlock() (which calls > pthread_mutex_unlock()) > - SGMutex desctructor : calls pthread_mutex_destroy() > > Looking at openthreads code, changing SGMutex to OpenThreads::Mutex does > this: > > - OpenThreads::Mutex constructor : calls pthread_mutex_init() > - SGGuard constructor : now calls OpenThreads::Mutex.lock() (which calls > pthread_mutex_lock()) > - SGGuard destructor : now calls OpenThreads::Mutex.unlock() (which > calls pthread_mutex_unlock()) > - OpenThreads::Mutex destructor : calls pthread_mutex_destroy() > > However, when compiling for win32, you will have specific win32 threads > managment calling EnterCriticalSection(), InterlockedExchange() etc > which should be more efficient. > > So the effects are: > - Do not worry about threads portability and always use optimized code > from osg which seems a very active project. > - Do not worry about threads-enabled/threads-disabled code, just check > if openthreads is there. > > Regards > Benoit ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
