Re: Thread-safe access to graphic objects - proposal

[Jaroslav Hajek]

On Thu, Jul 3, 2008 at 12:22 PM, Maciej Gajewski
<address@hidden> wrote:
> Hello everyone
>
> This is proposal of locking scheme for graphics object, making them
> safe to access from multiple threads.
>
> Rationale
> ========
>
> This is a snippet from discussion about Qt-based plotting/UI backend
> I'm currently working on:
>
>> > 3. In response for backend calls (close_figure, redraw_figure, print), send
>> > appropriate message to GUI thread, also copy object properties (syncing
>> > threads), so they can be safely accessed by GUI code from GUI thread.
>>
>> I used to do something similar in JHandles, but eventually dropped the
>> idea for efficiency (copying all props takes time) and maintenance
>> (keeping 2 property sets in sync, property addition...) reasons. The
>> main problem is then to avoid race conditions. I proposed a locking
>> scheme a few months ago on this mailing list, but we didn't really
>> reach an agreement. But I hope that in the future, octave will provide
>> a mechanism to access graphics object properties in a thread-safe
>> way, without having to duplicate all properties.
>
> As Michael Goffioul points, copying all properties from main thread to
> GUI thread, and then sending all properties changed by GUI back to
> main thread is hell.
> While just copying them one-way would be not so bad, sending changes
> back from GUI and synchronizing requires complicated and
> hard-to-maintain facilities.
>
> And GUI changes its properties pretty often: each time figure window
> is moved or resized, it's properties should change. Then: axes are
> zoomed, rotated, annotation can be added etc etc.
>
> This all could be made simple bu just adding locks in appropriate
> places in graphics.h /graphics.cc. Having thread-safe property access
> could allow GUI backend to simply read and modify it's properties at
> any time.
>
> Proposed implementation
> ======================
>
> 1. Use boost libraries. they are beautifully designed, crossplatform,
> plays well with std and are widely available.
> 2. Add one central mutex to gh_manager instance.
> 3a. Add lock() / lock_shared() / unlock() / unlock_shared() to gh_manager, or
> 3b. simply leave the mutex exposed, so anyone can lock/unlock it, or
> use locker object to get simple RAII locking.
> 4. Add appropriate locks/unlocks in graphics.cc, in places where:
>  * properties are modified,
>  * new objects are created,
>  * objects are destroyed,
>  * properties are read.
>
> Then - backend living in another thread could use the same locking
> mechanism to access/modify properties.
>
> Another idea is to lock in every property set/get method, but this
> would exclude case where objects are destroyed, possibly leaving GUI
> thread with dangling pointer. So IMO entire blocks of code obtaining
> object pointer from handle, then properties from object, then
> reading/manipulating them.
>
> Using boost RAII classes this could be pretty simple:
>
> void backend::readprops()
> {
>  shared_lock lock( gh_manager::get_mutex() ); // this obtains lock.
> For modification, use unique_lock instead.
>
>  // this is actual part of code from fltk and qt backend
>  graphics_object fobj = gh_manager::get_object (fh);
>  if (fobj &&  fobj.isa ("figure") )
>  {
>    // get properties
>    figure::properties& fp = dynamic_cast<figure::properties&>(
> fobj.get_properties() );
>
>    // read properties here... (or modify, if unique_lock used)
>  }
> } // here the lock dies, releasing mutex
>
> I volunteer to implement this, but I would need help adding
> appropriate checks/dependencies into build system.
>
> RFC
>
> Maciek Gajewski
>

Speaking of Boost - Octave could benefit of many of the Boost
libraries: multiarray, math/special functions, math/statistical
distributions, uBLAS, serialization, filesystem,
numeric conversion, smart ptr, string algo, and perhaps more...

If Octave takes the burden of dependence on Boost, then a lot code may
be rewritten to take advantage of it. For instance, the Array classes
can be based on multiarray, the ubiquitous reference counting can be
implemented using smart pointers, the special functions and
statistical distributions can be reused, system calls handled by the
system library ...
perhaps even the parser could eventually be rewritten using Spirit.
I'm not sure at this moment if Boost's portability matches (or
outmatches) Octave's - it would be a problem if it didn't, of course.

In February, the Boost license was approved by OSI as Open Source, so
this obstacle is now gone.

cheers,

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz