Nabble - XCSoar

Re: Shutdown exception error in Win32

2009-12-04T06:22:40Z

On Fri, 2009-12-04 at 09:07 +0100, Max Kellermann wrote:
> On 2009/12/04 08:06, John Wharington <jwharington@...> wrote:
...

> > All of the new task/waypoint/airspace work I have done lately does not
> > have any thread/locking code in it and I am not the right person to
> > design that aspect in.
>
> That's perfect, because backend libraries should not care about thread
> safety. Locking an object during a method call is wrong because the
> caller might be holding the lock already (recursive locks are
> cumbersome and error prone).
>
> In any case, the party which begins working with an object should do
> all the locking. It may pass locked (and const?) object references to
> "libraries". If you take "const" references of an object often
> enough, it may we worthwile to use RWLock instead of Mutex.
>
> So what we need to be aware of is the classification of all the code,
> regarding thread safety:
>
> library code:
> - generic reusable code
> - well documented interface
> - doesn't know or care about threading
> - doesn't have access to global variables (Components.hpp, ...)
> - doesn't declare any global/static variables
> - doesn't call glue code
> - libraries may use other libraries
> - but try not to create circular dependencies
> - you can write automated unit and coverage tests
> - examples: Math/*, Canvas, WindowControls, RasterMap, Airspace,
> WayPoint, ClimbAverageCalculator

OK. The ex_xcsoar stuff follows those guidelines pretty well. As I
said in an earlier post, it is all OO, no globals (other than static
constants), no locking, all documented, proper interfaces hiding
implementation (mostly). Most of the task system is already
implemented, as well as a new data structure storage for airspaces and
waypoints. I have test programs that exercise most of the code and
check this with lcov, and all tests run under the tap harness.

I can happily report that it compiles for PPC2003 and I have run some of
the tap tests on that platform and performance looks very good --- on my
PDA it takes 15 ms for a full task system time step update with all
features on: auto mc, auto target optimisation etc.

I have taken a new branch off the main xcsoar git and just as an
experiment, stripped out the old waypoint/airspace/task stuff with
#ifdefs and am ready to start hooking it up to the new system.

> glue code
> - the "dirty" code, which uses the libraries
> - everything is allowed, but we're trying hard to keep it down
> - responsible for creating threads and thread safety (mutual exclusion)
> - examples: UI code like MapWindow, the dialog implementations,
> DrawThread, InputEvents
>
> (That's a simplification; from other points of view, there are more
> types of code, but for the current locking discussion, this model is
> sufficient)
>
> There was very little library code in XCSoar <=5.2.x, almost
> everything was glue code (and nobody felt responsible for locking).
> Much of my work until now included extracting library code from glue
> code (e.g. Airspace, FlightStatistics). Leaning towards library code
> is a goal, because that will increase the overall quality and
> readability of the code.
>
> Examples of glue code which should be converted to library code:
>
> - GlideComputer

^^^^^ a lot of this stuff will be replaced with the new task system.

> - GlidePolar
^^^^^ will be replaced with the new task system.

> - InfoBoxLayout
> - AirspaceParser
^^^^^^ will be replaced with the new task system.

> - much of the rendering code
> - the global "qnh" variable must go away
^^^^^^ will be replaced with the new airspace system (that's why it is passed around)

> Example locking code (one idea for an API):
>
> class Foo { /* ... */ }; // no Mutex!
>
> class SafeFoo : protected Mutex, protected Foo {
> class Lease {
> SafeFoo &foo;
> Lease(SafeFoo &_foo):foo(_foo) { foo.Lock(); }
> ~Lease():foo(_foo) { foo.Unlock(); }
> Foo *operator ->() { return &foo; }
> Foo &operator *() { return foo; }
> };
> };
>
> (SafeFoo can be implemented as a template class)

OK, this is good. I will have (or already have) abstract interfaces for
the classes that the main program will be expected to talk to.

> The idea is that the class Foo is pure library code, but is never used
> directly. Only the derived class SafeFoo is used by the glue code,
> while the library code only ever sees "Foo&" references. So how do
> you use it?
>
> static SafeFoo foo;
>
> void do_something() {
> SafeFoo::Lease lease(foo);
> lease->do_this_and_that();
> other_object.handle_foo(*lease);
> }
>
> It is impossible to use the "foo" variable without locking it
> properly. Since the base classes are "protected", you cannot access
> them from the outside. The compiler is your friend, in this case he
> verifies the locks you hold.
>
> (Caution! I have not compiled the above code, up to now this is just
> unchecked theory)

OK, that sounds good.

> Caution II: it's not as easy as it sounds; if you hold more than one
> lock at a time, you may deadlock - the locking order is important.
> Note that with the current code base, you have no control over this
> order, because everybody and nobody is responsible for locking.

That's a bit of a problem, yes.

> So far about thread synchronization. Communication is another large
> topic, and I think the current code is a large improvement over 5.2.4
> (copies of all important objects). Before we can go on, we need some
> kind of survey on which thread needs to communicate what; who
> receives GPS data, who calculates what, who broadcasts all that to the
> other threads, ...

Yep. As you know, that is what I had been trying to get a handle on
when working on the current head code (and that's why I was strict about
const and non-const copies of data structures etc). There are only a
few data elements that need to be written by more than one thread, this
can be done better by a message queue potentially.

It's getting clearer.

One area I am struggling in principle with is how locking should best be
done with task editing. You shouldn't lock the task for the duration of
the edit, so for example if you are editing a particular turnpoint's
parameters really you need to make a copy (unlock), edit the copy at
leisure, then somehow copy the changes back in locked scope again.

Without actually implementing any of the locking, I prototyped something
like this in the ex_xcsoar/Test/test_edittp.cpp

> Next large topic: serialization (e.g. xcsoar-persist.log). I think we
> agree that writing raw classes to a file isn't a good idea, especially
> when that includes the vtable pointer and probably objects such as
> Mutex. My idea: use C++ iostreams.
>
> ostream &operator <<(ostream &os, const Foo &foo) {
> return os << Foo::VERSION << foo.GetThis() << foo.getThat();
> }
> With this operator overloaded for enough classes, we can simply say
> "os << foo" and we're done. Same for loading from the file: "os >>
> foo".

Suits me fine, and in fact I am using ostreams for debugging output, so
I am somewhat ready for that approach.

> Care should be taken to write platform independent binary
> representations, so you can put the SD card of the ARM PDA into your
> PC and use XCSoar-PC to edit the files. The serialization version
> written before each object shall ensure backwards compatibility in the
> future.
>
> Max

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Xcsoar-devel mailing list
Xcsoar-devel@...
https://lists.sourceforge.net/lists/listinfo/xcsoar-devel

Nabble - XCSoar

Re: Shutdown exception error in Win32

Re: Shutdown exception error in Win32

Re: Shutdown exception error in Win32

Re: Shutdown exception error in Win32

Re: Shutdown exception error in Win32

Re: Shutdown exception error in Win32

Re: Shutdown exception error in Win32

Re: Shutdown exception error in Win32

Re: Shutdown exception error in Win32

Re: Shutdown exception error in Win32

Re: Shutdown exception error in Win32

Re: Shutdown exception error in Win32

Shutdown exception error in Win32

Re: Binetone vs Garmin ?

Re: Binetone vs Garmin ?

Binetone vs Garmin ?

Re: XC Soar Status

UK Airspace text file.

Re: Pushed 61 patches: Borland, regression fixes, RunMapWindow

Re: XC Soar Status

Re: XC Soar Status

Re: XC Soar Status

Re: XC Soar Status

Re: XC Soar Status

XC Soar Status

Pushed 61 patches: Borland, regression fixes, RunMapWindow

Pushed 15 patches: code cleanup

Pushed 30 patches: Code cleanup & separation

Pushed 52 patches: code cleanup, global variables

Pushed 41 patches: code cleanup, documentation

Re: Pushed 21 patches: backboard refactoring, code cleanup

Pushed 21 patches: backboard refactoring, code cleanup

Pushed 38 patches: object oriented device drivers

Re: Eclipse project files

Pushed 46 patches: Documentation, Eclipse, device refactoring