I am just curious to know if there is any additional cost to a sketch - on any level, memory consumption probably being the most important as well as clock cycle consumption - when declaring a variable as being volatile vs. not declaring it as volatile.

[image] EasyGoing1: But when writing libraries, we can only do what we can do within our domain and hope that the developer chooses their libraries wisely and has the ability to find answers to problems that might happen. IMO, not a realistic view. As mentioned earlier, FreeRTOS can separate threads and resources. In the ESP32 which has been around Arduino-land for a few years, the initial RTOS is installed pre-configured with the ESP32: Core_0 and Core_1 (Arduino) are completely separated. The RP2040, one common core is here: GitHub - earlephilhower/arduino-pico: Raspberry Pi Pico Arduino core, for all RP2040 boards and states: The SMP (multicore) port of FreeRTOS is included with the core. This allows complex task operations and real preemptive multithreading in your sketches. While the setup1 and loop1 way of multitasking is simplest for most folks, FreeRTOS is much more powerful. FreeRTOS implementation on RD2040

[image] EasyGoing1: And MY problem - is ignorance ... the terms 'Semaphore' and 'Mutex' have no frame of reference in my mind They're documented in the SDK Guide that you linked back in Post #23

[image] mrburnette: FreeRTOS implementation on RD2040 The RTOS method that you're referring to ... is not something I've seen before. So Im going to read up on what you've posted here.

[image] EasyGoing1: The library was written long before the Pico even existed. Libraries typically check the controllers which they support and for which they are compiled. No problem to provide separate libraries for various architectures.

[image] DrDiettrich: Libraries typically check the controllers which they support and for which they are compiled. No problem to provide separate libraries for various architectures. I've seen libraries that do that of course ... but when I first started writing the library, the concept was very simple ... record the value of millis() during instantiation, then when the call to the triggered() method happens, compare the current value of millis() against the recorded value and see if the delta is greater than or equal to the defined duration of the timer. Such a simple thing would be possible with any arduino that can be developed on using the Arduino IDE. In other words, nothing that the library is doing has any dependence on any specific platform and all platforms should have no issues at all running the library. if the platform understands millis() and can store an unsigned long variable, then its compatible. And I wouldn't know how to check - via code - whether or not a platform can do millis() and store unsigned long variables. I am assuming they all can. That would not be true where a library has code that must make calls in reference to hardware specific features. Which this library does not do.

So after looking at everything, the only thing that can be changed once the library has been instantiated, is the duration of the timer. And the variable that I use to hold that value is actually a union. And that union looks like this: union cTime { double seconds; class milli_t { double seconds; public: milli_t &operator=(double ms) { seconds = ms * .001; return *this; } operator double() const { return seconds * 1000.0; } } millis; class micro_t { double seconds; public: micro_t &operator=(double us) { seconds = us * .000001; return *this; } operator double() const { return seconds * 1000000.0; } } micros; }; I tested this code change in the header file and it compiles just fine without a problem: #ifdef BLOCKNOT_THREAD_SAFE volatile cTime duration; #else cTime duration; #endif So then at this point, the only thing that someone would need to do if they wanted a "thread safe" instantiation of the library would be to add this to their code before instantiating the library: #define BLOCKNOT_THREAD_SAFE And since that is defined, then the duration variable will declare the union as being volatile where standard use of the library will have no effective change at all. Does anyone see a problem with this option?

[image] EasyGoing1: So then at this point, the only thing that someone would need to do if they wanted a "thread safe" instantiation of the library would be to add this to their code before instantiating the library: #define BLOCKNOT_THREAD_SAFE Maybe yes, maybe no. Depends on how the library is split between .h and .cpp files as well as how the user integrates it into their code.

[image] gfvalvo: Maybe yes, maybe no. Depends on how the library is split between .h and .cpp files as well as how the user integrates it into their code. But under what conditions would it be a problem? If you're interested, the library is here.

[image] EasyGoing1: #define BLOCKNOT_THREAD_SAFE Where should that #define reside? It must be active when the library is compiled, what happens out of user code.

Cost of Volatile variables?

Projects Programming

mrburnette September 21, 2022, 7:07pm 39

Very simple Arduino implementation of workload bound to a thread:

ESP32 - using 2nd core - Using Arduino / Programming Questions - Arduino Forum

Topic		Replies	Views
A good pattern for removing globals and guaranteeing that the serial port is set up before anything else Programming	29	561	September 24, 2026
Setting up interrupts in the ATTiny85 Digispark Digistump Programming	101	1656	June 13, 2026
Arduino Non-Blocking Heartbeat Without Any Variables Programming	77	1208	July 12, 2026
Millis() auf einen Startwert setzen, um Overflow zu testen Deutsch	51	5135	December 2, 2021
Delay with millis: unexplicable behaviour Programming	47	848	March 8, 2025

Cost of Volatile variables?

Related topics