till busch wrote:
> 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.
I'm generally supportive of this kind of work too. Replacing home-grown code
with packages that have a larger user base eases our own development and testing
In this specific case Benôit seems to have missed that SGThread is used in
flightgear for the metar and voice threads, at least on Linux, so we can't just
eliminate SGThread yet, but it does seem safe to eliminate SGMutex.
> 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
>> - SGGuard destructor : calls SGMutex.unlock() (which calls
>> - SGMutex desctructor : calls pthread_mutex_destroy()
>> Looking at openthreads code, changing SGMutex to OpenThreads::Mutex does
>> - OpenThreads::Mutex constructor : calls pthread_mutex_init()
>> - SGGuard constructor : now calls OpenThreads::Mutex.lock() (which calls
>> - 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.
> 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.
> Flightgear-devel mailing list