Is it necessary to use mutexes between uGFX created threads?

[kengineer]

Or is this already handled? I've seen calls to them in the code so I'm guessing it is but want to verify. But for example, if I'm using a variable that gets called by a GTIMER callback and the GINPUT thread...

[inmarket]

UGfx relies on two threads, the main thread for the users application and a gtimer thread. The user may of course add extra threads for their application. Ginput code usually ends up running on the gtimer thread as part of a gtimer event. All gtimer events effectively run synchronously on the one thread. Doing things this way keeps stack use as small as possible.

Mutexes are needed to protect objects and api calls where...

1/ uGFX might call gfxYield or one of the gfxSleep calls; or

2/ where the underlying thread implementation is preemptive. The raw32 thread implementation for example is non-preemptive and so this clause 2 doesn't apply.

Note that generally mutexes are cheap. They tend to have very little overhead unless the mutex is already taken (likely to be an uncommon occurance). The unfortunate side is that they can take up space in structures (increasing the structure size and therefore ram requirements) and they introduce code complexity. 

Still if you are runnung in a multithreaded environment then they are required.