Hanging by a Thread

The place to brainstorm ideas related to Modeling, Simulation and OpenEaagles.

Hanging by a Thread

Postby kyle » Sun Feb 22, 2009 1:35 pm

There is an occasional segfault that occurs in OE apps, during shutdown. The cause, I finally was able to determine, is the way OE handles threads during shutdown - which is not at all. In the attached tarball, find two patchfiles:

station_threading.patch:
- adds bgThreadFunc, netThreadFunc, and tcThreadFunc to class Station, as static member functions.
- adds a thread handle for the bg Thread, net Thread, and tc Thread to class Station as private member data.
- adds a call to pthreads_join to Station::deleteData(), which causes the main thread to wait for all child threads to complete before deleting the Station object (the source of the segfault is that the station object is deleted, while the children are still trying to use its resources.)
- Fixes a signed integer overflow in the main loops of all three ThreadFunc's, where i >0 is only true for the first 2^31-1 iterations (0x7FFFFFFF +0x1 = -0x80000000), by removing the iterators (the variable i) from the loops, and placing the starttime variable assignment outside of the loop.

threadeddevice_shutdowwait.patch:
- adds a shutdown signal by which the main thread can signal the child thread (s) to shut down
- adds a call to pthreads_join() to ThreadedDevice::stopAsync
- Fixes a signed integer overflow in the main loop of recieveThread, by removing the iterator (the variable i) from the loop, and moving the tastTime assignment to the bottom of the loop.

threadeddevice_shutdwonwait.patch is in its own patch file, because the deviceIO interface has been re-written in the current development version of OE, so this patch is potentially irrelevant.
Also, given that I am not a windows programmer, I have no idea how to handle windows threading. I did what I could, but I don't know enough about it to know what to do to join a windows thread. Thus, while I created #ifdefs to handle linux vs windows, the windows parts are empty and/or wrong, and should be looked at by a windows programmer.

all patches are against 8.10
Attachments
threadingpatches.tar.gz
(3.66 KiB) Downloaded 52 times
kyle
 
Posts: 50
Joined: Mon Apr 21, 2008 10:44 am

Re: Hanging by a Thread

Postby doug » Mon Feb 23, 2009 10:22 pm

Kyle,

Thanks! We will incorporate, along with the other issues mentioned, such as player removal.

Sorta swamped at the moment, but catching up...

Can you post the updated Station class? I prefer to use WinMerges with changes.

Thanks for the input! (I like the subject title!)

Doug
doug
Site Admin
 
Posts: 206
Joined: Tue Jan 01, 2008 10:00 pm

Re: Hanging by a Thread

Postby kyle » Tue Feb 24, 2009 2:08 pm

Here ya go.
Attachments
Station.cpp
(47.35 KiB) Downloaded 49 times
ThreadedDevice.h
(1.27 KiB) Downloaded 52 times
Station.h
(11.38 KiB) Downloaded 52 times
kyle
 
Posts: 50
Joined: Mon Apr 21, 2008 10:44 am

Re: Hanging by a Thread

Postby kyle » Tue Feb 24, 2009 2:09 pm

Here's the last one (I can only add three at once). hmm probably should have tar'ed them. Cest la vie....
Attachments
ThreadedDevice.cpp
(4.75 KiB) Downloaded 52 times
kyle
 
Posts: 50
Joined: Mon Apr 21, 2008 10:44 am

Re: Hanging by a Thread

Postby doug » Wed Feb 25, 2009 9:19 pm

Thanks... we are "catching up" on all these fixes and suggestions. Another thought is to have each thread reference the Station class, then the problem should go away. Nevertheless, your code will stay.

Another thought is make a thread class for OE that can manage all of this... anyway, thanks for the input!

Doug
doug
Site Admin
 
Posts: 206
Joined: Tue Jan 01, 2008 10:00 pm

Re: Hanging by a Thread

Postby kyle » Thu Feb 26, 2009 5:03 pm

That would work, actually. I like your idea of an Eaagles Thread class better though, because Eaagles has a LOT of threads, and their interfaces and interactions with the rest of the framework vary a bit. A thread class would standardize that, reducing a potential vector for introducing bugs. Also, it would make it easier for framework users to create their own threads that integrate will with the framework.

I would recommend looking at the Boost::Threads library, and perhaps having the Eaagles Thread class subclass from that. Boost::Threads is one of the fastest, and easiest to use Threading libraries available to C++.

Lastly, my patch has a bit of an error in it. Station::deleteData() should call shutdownNotification(), and NOT BaseClass::deleteData(), as I originally coded it.
kyle
 
Posts: 50
Joined: Mon Apr 21, 2008 10:44 am

Re: Hanging by a Thread

Postby catherina » Fri May 08, 2009 2:45 pm

Thanks... we are "catching up" on all these fixes and suggestions. Another thought is to have each thread reference the Station class, then the problem should go away. Nevertheless, your code will stay.

simulation emprunt immobilier
catherina
 
Posts: 2
Joined: Fri May 08, 2009 2:24 pm

Re: Hanging by a Thread

Postby kyle » Mon Aug 31, 2009 6:53 pm

More threading issues in station.

Upon subclassing station, so I could define inputDevices() and outputDevices(), I discovered that the way threads are currently handled*, I discovered that the segfault my original patch fixed comes back, when using subclass member objects in those functions. Only the solution this time is more complicated: The sublcass' deleteData function gets called before Station::deleteData(), wherein all threading stops. subclass:::deleteData(), which is responsible for deconstructing the subclass, deletes it's member objects, which are referenced by inputDevices() and outputDevices() in the subclass, which are both called via Station::updateTC(), which is still being called, because threading has not stopped, and will not stop until Station::deleteData() is called. Hence, the subclass causes a segfault.

I looked at using a smart pointer, and various other locking mechanisms, but nothing is capable of completely fixing the problem, other than shutting down the RT thread during or before subclass::deleteData().

the following Station.h and Station.cpp files add a public function, endRealTimeProcess(), which shuts down the RT thread. It is made public, so as to provide more flexibility, and a more consistent interface, due to createRealTimeProcess() also being public.

*I say currently handled, although I notice that the latest version of OE contains the same bugs this thread was created to address. Hence, I had to go back to 8.10 to provide a fix to correctly working files....
Attachments
Station.h
(11.43 KiB) Downloaded 41 times
Station.cpp
(47.56 KiB) Downloaded 44 times
kyle
 
Posts: 50
Joined: Mon Apr 21, 2008 10:44 am


Return to Off Topic

Who is online

Users browsing this forum: No registered users and 1 guest

cron