zephyr/samples/kernel/condition_variables/condvar
Gerard Marull-Paretas 79e6b0e0f6 includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.

The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.

NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-09-05 16:31:47 +02:00
..
src
CMakeLists.txt
README.rst
prj.conf
sample.yaml

README.rst

.. _samples_kernel_condvar:

Condition Variables
###################

Overview
********

This sample demonstrates the usage of condition variables in a
multithreaded application. Condition variables are used with a mutex
to signal changing states (conditions) from one thread to another
thread. A thread uses a condition variable to wait for a condition to
become true. Different threads alternate between their entry point
function execution based on when they signal the other thread that is
pending on the condition variable. The sample can be used with any
:ref:`supported board <boards>` and prints the sample output shown to
the console.

Building and Running
********************

This application can be built and executed on Native Posix as follows:

.. zephyr-app-commands::
   :zephyr-app: samples/kernel/condition_variables/condvar
   :host-os: unix
   :board: native_posix
   :goals: run
   :compact:

To build for another board, change "native_posix" above to that board's name.

Sample Output
=============

.. code-block:: console

    Starting watch_count: thread 1
    watch_count: thread 1 Count= 0. Going into wait...
    inc_count: thread 2, count = 1, unlocking mutex
    inc_count: thread 3, count = 2, unlocking mutex
    inc_count: thread 2, count = 3, unlocking mutex
    inc_count: thread 3, count = 4, unlocking mutex
    inc_count: thread 2, count = 5, unlocking mutex
    inc_count: thread 3, count = 6, unlocking mutex
    inc_count: thread 2, count = 7, unlocking mutex
    inc_count: thread 3, count = 8, unlocking mutex
    inc_count: thread 2, count = 9, unlocking mutex
    inc_count: thread 3, count = 10, unlocking mutex
    inc_count: thread 2, count = 11, unlocking mutex
    inc_count: thread 3, count = 12  Threshold reached.Just sent signal.
    inc_count: thread 3, count = 12, unlocking mutex
    watch_count: thread 1 Condition signal received. Count= 12
    watch_count: thread 1 Updating the value of count...
    watch_count: thread 1 count now = 137.
    watch_count: thread 1 Unlocking mutex.
    inc_count: thread 2, count = 138, unlocking mutex
    inc_count: thread 3, count = 139, unlocking mutex
    inc_count: thread 2, count = 140, unlocking mutex
    inc_count: thread 3, count = 141, unlocking mutex
    inc_count: thread 2, count = 142, unlocking mutex
    inc_count: thread 3, count = 143, unlocking mutex
    inc_count: thread 2, count = 144, unlocking mutex
    inc_count: thread 3, count = 145, unlocking mutex
    Main(): Waited and joined with 3 threads. Final value of count = 145. Done.