Lines Matching refs:is
15 In the context of this document, a thread is any sequence of CPU instructions.
30 If operation X is atomic, that means that any thread observing the operation will
31 see it either as not yet started, or as completed, and not in any state that is
35 interfere with it, then operation X is not atomic.
46 A datum (i.e. contents of a variable or data structure) is atomic if any thread
49 state that is partially changed or otherwise inconsistent.
51 When reading or writing a value is started and completed with 1 CPU instruction,
52 it is automatically atomic, since it can never been seen in an inconsistent
54 values, no special protection is required by programmers to ensure all threads
64 LVGL is **not thread-safe**.
66 That means it is the programmer's responsibility to see that no LVGL function is
67 called while another LVGL call is in progress in another thread. This includes calls
71 Assuming the above is the case, it is safe to call LVGL functions in
76 because the thread that drives both of these is the thread that calls
88 before any other LVGL function is started.
96 - :cpp:func:`lv_tick_inc` (if writing to a ``uint32_t`` is atomic on your
100 The reason this is okay is that the LVGL data changed by them is :ref:`atomic <atomic>`.
121 Under an OS, it is common to have many threads of execution ("tasks" in some OSes)
126 Yet it still remains the programmer's responsibility to see that no LVGL function is
127 called while another LVGL call is in progress.
136 A "Gateway Thread" (or "Gateway Task" in some OSes) is a thread (task) that the
137 system designer designates to *exclusively* manage a system resource. An example is
139 be brought into a consistent state before something new is started. Another example
140 is management of multiple devices on an I2C bus (or any data bus). In this case the
141 I2C bus is the "exclusively-managed resource", and having only one thread managing it
142 guarantees that each action started is allowed to complete before another action with
143 it is started.
150 that thread is also the ONLY caller of :cpp:func:`lv_timer_handler`. (See
155 data structures. This is enforced by programmer discipline that ensures the `Gateway
156 Thread`_ is the only thread making LVGL calls (excluding the :ref:`exceptions
159 If `atomic data`_ relevant to the user interface is updated in another thread (i.e.
161 data directly without worry that it is in an inconsistent state. (To avoid
163 updating thread] so that the user interface is only updated when it will result in a
166 If `non-atomic data`_ relevant to the user interface is updated in another thread
168 data to the thread calling LVGL functions is to pass a private copy of that data to
178 A MUTEX stands for "MUTually EXclusive" and is a synchronization primitive that
191 is complete.
194 that thread waits on the other thread to release (unlock) it before it is allowed
200 If a MUTEX is used to protect LVGL data structures, that means *every* LVGL function
205 If your OS is integrated with LVGL (the macro :c:macro:`LV_USE_OS` has a value
209 When this is the case, :cpp:func:`lv_timer_handler` calls :cpp:func:`lv_lock()`
213 If your OS is NOT integrated with LVGL, then these calls either return
227 time_till_next = lv_timer_handler(); /* lv_lock/lv_unlock is called internally */
267 timer_stop(); /* Stop the timer where lv_tick_inc() is called */
279 timer_start(); /* Restart timer where lv_tick_inc() is called */