From: Johan M. <joh...@gm...> - 2010-09-28 12:51:55
|
Hi I am trying to display several curves with updates in real time of the displayed values. In order to do this, I launch my main window with GTK/Cairo/PLplot in the main program and a thread that generate the values to be displayed. All of this being coded in Ocaml through dedicated bindings. Each time that I need to change a curve from the thread, I reinitialize the plplot stream and create a new one with new values. However, since I am using Cairo driver inside GTK, the generated graphs and window are also affected by GTK handler launched by signals that redraws the widget and thus the curves. And unfortunately, some of these handler sometime launch at the same time as I am modifying some curves. This produces an error because some plplot stream are affected by commands in the wrong order (commands from the redraw in the handler and from the function to redraw curves with new values). I tried to avoid this by the use of mutexes that forbids the use of some function from both the main window with GTK/Cairo/PLplot and from the thread. However, this is not working. My guess is that GTK and its Ocaml bindings, lablgtk, are handling threads and mutexes in a special way. But my knowledge on this point is very sparse. And it would be very helpful if someone could help me on this point. Thanks in advance for your time. Regards. Johan Mazel |
From: Johan M. <joh...@gm...> - 2010-09-29 11:49:18
|
Hi I fixed this problem. The solution is to used a global mutex that forbids any simultanate use of PLplot primitives. Especially when you are using class to handle each graph. Each class handling a graph need to use this mutex to synchronize itself with all the other graphs. I don't know in which way my first implementation with mutexes was wrong but this implementation fixes the problem. Regards. Johan Mazel 2010/9/28 Johan Mazel <joh...@gm...> > Hi > I am trying to display several curves with updates in real time of the > displayed values. In order to do this, I launch my main window with > GTK/Cairo/PLplot in the main program and a thread that generate the values > to be displayed. > All of this being coded in Ocaml through dedicated bindings. > > Each time that I need to change a curve from the thread, I reinitialize the > plplot stream and create a new one with new values. > However, since I am using Cairo driver inside GTK, the generated graphs and > window are also affected by GTK handler launched by signals that redraws the > widget and thus the curves. > > And unfortunately, some of these handler sometime launch at the same time > as I am modifying some curves. This produces an error because some plplot > stream are affected by commands in the wrong order (commands from the redraw > in the handler and from the function to redraw curves with new values). > I tried to avoid this by the use of mutexes that forbids the use of some > function from both the main window with GTK/Cairo/PLplot and from the > thread. > However, this is not working. > > My guess is that GTK and its Ocaml bindings, lablgtk, are handling threads > and mutexes in a special way. > But my knowledge on this point is very sparse. And it would be very helpful > if someone could help me on this point. > > Thanks in advance for your time. > > Regards. > Johan Mazel > |
From: Hezekiah M. C. <hez...@us...> - 2010-09-29 15:22:16
|
On Wed, Sep 29, 2010 at 7:49 AM, Johan Mazel <joh...@gm...> wrote: > Hi > I fixed this problem. > The solution is to used a global mutex that forbids any simultanate use of > PLplot primitives. > Especially when you are using class to handle each graph. Each class > handling a graph need to use this mutex to synchronize itself with all the > other graphs. > > I don't know in which way my first implementation with mutexes was wrong but > this implementation fixes the problem. > > Regards. > Johan Mazel > Johan, I'm glad you got it to work! I have/had an OCaml + PLplot + Gtk + threads example sitting on my drive somewhere, but I haven't been able to find it. Your solution is close to what I used. PLplot is not thread-safe internally, so it is very important to only allow one thread to utilize PLplot at a time. Hez |
From: Schwab,Wilhelm K <bs...@an...> - 2010-09-29 15:45:57
|
Hez, Just a gut reaction, but it seems a reasonable goal/expectation would be that the library should be thread-safe at the stream level, meaning that once a stream is created (and probably while listed in what is a globally mutex-protected list), independent threads can safely use separate streams. Using thread-local storage rather than globals might go a long way to allow that. Comments? Bill ________________________________________ From: Hezekiah M. Carty [hez...@us...] Sent: Wednesday, September 29, 2010 11:16 AM To: Johan Mazel Cc: plp...@li... Subject: Re: [Plplot-general] Error using threads, GTK and Cairo driver On Wed, Sep 29, 2010 at 7:49 AM, Johan Mazel <joh...@gm...> wrote: > Hi > I fixed this problem. > The solution is to used a global mutex that forbids any simultanate use of > PLplot primitives. > Especially when you are using class to handle each graph. Each class > handling a graph need to use this mutex to synchronize itself with all the > other graphs. > > I don't know in which way my first implementation with mutexes was wrong but > this implementation fixes the problem. > > Regards. > Johan Mazel > Johan, I'm glad you got it to work! I have/had an OCaml + PLplot + Gtk + threads example sitting on my drive somewhere, but I haven't been able to find it. Your solution is close to what I used. PLplot is not thread-safe internally, so it is very important to only allow one thread to utilize PLplot at a time. Hez ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Plplot-general mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-general |
From: Hezekiah M. C. <hez...@us...> - 2010-09-30 02:11:11
|
On Wed, Sep 29, 2010 at 11:45 AM, Schwab,Wilhelm K <bs...@an...> wrote: > Hez, > > Just a gut reaction, but it seems a reasonable goal/expectation would be that the library should be thread-safe at the stream level, meaning that once a stream is created (and probably while listed in what is a globally mutex-protected list), independent threads can safely use separate streams. Using thread-local storage rather than globals might go a long way to allow that. Comments? > > Bill > Bill,, I agree that this would be ideal. However, several pieces of PLplot's internals use global variables to manage state, preventing isolation of each individual stream. Most of these pieces stretch many years back in PLplot's history, so they will take some time to cleanly remove. That said, I agree that thread safety at the stream level is something we should work toward. Identification of portions of PLplot code which are per-stream thread safe and/or patches would be very helpful! If all of the portions of PLplot which prevent stream-level thread safety are identified then it will make it much simpler to update PLplot successfully. Further discussion on this should probably move to the PLplot development list. Thank you for your interest in pushing PLplot forward! Hez |