FLTK Lock Behavior

[Rob McDonald]

Does the FLTK lock guarantee that requests are fulfilled in the order they are received?  I.e. a FIFO behavior?

I am not using the FLTK lock in a normal GUI way (where the limitations of a human apply)...  My program is actually running in a thread in Python.  The GUI is launched from that thread.

Python has another thread running that receives API calls for my program.  When it receives them, it acquires the FLTK lock and executes the API call (my program is not thread safe).

Since the FLTK lock had to be running anyway (for the GUI), it seemed like this was the simplest way to make it all work.

I'm seeing some strange behavior that might be because 1) the API side is receiving calls faster than they can be handled.  2) the calls are then executed out of order.

I'm just at the start of debugging this, so I'm not positive this is what is going on.

Thanks for any insight.

Rob

[imm]

It may actually depend on what host system you are on...

There's no "queue" of locks held by fltk as such, the call just blocks on the lock (if it is not immediately available.)

If multiple threads are waiting when the lock is released, which of those gets to run first will generally depend on the scheduling policy of the host system. Some systems do (or at least can) use FIFO ordering, but some do not. In that case which thread gets to run is determined by arcane rules within the host scheduler...

Some systems will let you choose the scheduling policy so it may be possible to request FIFO ordering and see if that helps.

Another option might be to look at using the Fl::awake callback scheme to enact your updates. The awake callbacks are held in a queue within fltk and are serviced in FIFO order.

Plus the awake callback may be "smoother" if there's a lot of events as it allows the threads to proceed immediately rather than blocking on the single lock...

--
Ian
From my Fairphone FP3

[Greg Ercolano]

On 7/11/24 10:47, Rob McDonald wrote:

Does the FLTK lock guarantee that requests are fulfilled in the order they are received?  I.e. a FIFO behavior?

I don't think there's any guarantee of wake ordering, FIFO or otherwise.
It's more left to chance dependent on the OS's cpu/thread scheduling.

At least in the posix unix pthreads case; I don't know about windows.

Internally Fl::lock() in the posix unix context uses pthread_mutex_lock(), e.g.

--src/drivers/Posix/Fl_Posix_System_Driver.cxx:
static void lock_function_std() {
  if (!counter || owner != pthread_self()) {
    pthread_mutex_lock(&fltk_mutex);
    owner = pthread_self();
  }
  counter++;
}

There are some caveats, as there's also a recursive lock option that adds the PTHREAD_MUTEX_RECURSIVE flag to the lock, but I don't think that affects ordering either.

The man page for pthread_mutex_lock() doesn't mention anything about queuing or ordering, so that would seem to imply that which ever thread is scheduled by the operating system to wake up after a lock release is the one that gets the lock next, which is dependent on the operating system's cpu/thread scheduling, which is basically left entirely, assuming thread priorities are equal.

See also this stackoverflow post which asks your same question, and if one needs queuing, that article references another on how to implement FIFO locking.

[Greg Ercolano]

    Oops, small correction to my last post:

On 7/11/24 11:36, Greg Ercolano wrote:

[..] which is basically left entirely to chance, assuming thread priorities are equal. [..]

    Also, what Ian said; I didn't see his post until just now.

[Rob McDonald]

On Thursday, July 11, 2024 at 11:40:07 AM UTC-7 er...@seriss.com wrote:

    Also, what Ian said; I didn't see his post until just now.

Thanks much to you both, I'll see what I can come up with.

Rob

 

[Basile Starynkevitch]

If your program runs on Linux or POSIX systems, a possible approach is
to use the pipe to self trick to communicate between threads.

https://cr.yp.to/docs/selfpipe.html

--
Basile STARYNKEVITCH <bas...@starynkevitch.net>
8 rue de la Faïencerie, 92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/ -gives my mobile number +33 6 8501 ....
See/voir: https://github.com/RefPerSys/RefPerSys