logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

ESP-32 Dual Core Variable Sharing: Ensuring Safe Read/Write Access

michalek002a 2847 13
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
Report a violation of the law
Reply | New topic
  • #1 19782223
    michalek002a
    Level 6  
    Posts: 357
    Help: 8
    Rate: 72
    Hi. I want to use two cores in ESP-32 and have the two cores use the same variables. I'm just wondering how to make it so that when one core writes data to a variable, the other core doesn't start reading it, because some strange things might come out. Shouldn't there be a problem with this though?
  • ADVERTISEMENT
  • Helpful post
    #2 19782267
    freebsd
    Level 42  
    Posts: 6790
    Help: 766
    Rate: 2025
    michalek002a wrote:
    However, shouldn't there be a problem with that?
    Very good intuition. In C you can use "volatile", but in general you should look up "atomic operations", "semaphores" for the language you are programming in.
    Ps.: It is worth, but definitely worth, taking an interest in the Rust language for concurrent programming. I don't know what its status is for the ESP32, and I would add that it is not a straightforward language, but having dealt with large HPC systems I didn't know there was so much I could still learn :-) .
  • ADVERTISEMENT
  • #3 19782858
    PrawieElektronik
    Level 10  
    Posts: 29
    Help: 4
    Rate: 5
    The commonly mentioned "volatile" is not a cure for the aforementioned issues. It is merely a wish not to cache a variable in the CPU registers, but to force it to be deposited into RAM.

    It is indeed appropriate to talk about synchronisation.

    ALE. .
    Depending on the class of the issue, you can get synchronised to death, steam will go to the whistle even 50% of one CPU.
    There should be as little of this as possible, which should be achieved by a good algorithm preparation strategy.
    In different domains, computer science has different proposals for the use of cores, so that as little as possible cores "walk on each other's toes"

    What are you preparing, what issue?
  • Helpful post
    #4 19784946
    Anonymous
    Level 1  
  • ADVERTISEMENT
  • ADVERTISEMENT
  • #7 19785222
    freebsd
    Level 42  
    Posts: 6790
    Help: 766
    Rate: 2025
    khoam wrote:
    What is this quote from wikipedia supposed to serve? I remind you that the topic of the thread is ESP32, and therefore FreeRTOS.
    To expand on the concept of "mutexes".
  • #8 19785234
    Anonymous
    Level 1  
  • #9 19785243
    freebsd
    Level 42  
    Posts: 6790
    Help: 766
    Rate: 2025
    khoam wrote:
    Mutexes are used for this purpose, i.e. to synchronise the writing/reading of the same data by different threads of a program.
    Mutex is a broader concept and does not just refer to "writing/reading the same data".
  • #10 19785250
    Anonymous
    Level 1  
  • #11 19785259
    freebsd
    Level 42  
    Posts: 6790
    Help: 766
    Rate: 2025
    khoam wrote:
    In the link to the documentation I provided in the previous post, a colleague can expand his knowledge on the subject.
    Kindly thank you for your concern :-) , but professionally I have not been involved in such small systems for a long time - now it's just a hobby, time permitting, especially as ESP32 does not thrill me.
  • #12 19800187
    michalek002a
    Level 6  
    Posts: 357
    Help: 8
    Rate: 72
    PrawieElektronik wrote:
    The commonly mentioned "volatile" is not a cure for the aforementioned issues. It is merely a wish to not cache a variable in the CPU registers, but to force it to be deferred to RAM.

    It is indeed appropriate to talk about synchronisation.

    ALE. .
    Depending on the class of the issue, you can get synchronised to death, steam will go to the whistle even 50% of one CPU .
    There should be as little of this as possible, which should be achieved by a good algorithm preparation strategy.
    In different domains, computer science has different proposals for the use of cores, so that as little as possible cores "walk on each other's toes"

    What are you preparing, what issue?
    .
    I need to read and write data to the SD card on the fly, while executing the program uninterrupted. I haven't actually checked what read/write speed I'll have yet, but wanted to be safe.
  • #13 19800415
    Anonymous
    Level 1  
  • #14 19801147
    JacekCz
    Level 42  
    Posts: 8670
    Help: 760
    Rate: 1460
    michalek002a wrote:
    I need to read and write data to the SD card in real time, while executing the program uninterrupted. In fact, I haven't yet checked what read/write speed I'll have, but I wanted to take precautions.
    .

    Programs run in blocks of algorithm, blocks/groups of data .... so in some sense they are "intermittent".
    With good planning this can be done nicely, e.g. by portioning the data from block to block, and then treating it as immutable. Then the synchronised elements are reduced to a minimum.

    Good structuring of data and code is more important than coder tricks with unstructured data.
    There are already more resources available on the ESP, it can be programmed in a decent way, in layers/blocks/objects (since the Atmega 8 has an event queue, simple as it is, but it was there).
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion centers on the challenges of using dual cores in the ESP-32 for shared variable access, emphasizing the need for synchronization to prevent data corruption during concurrent read/write operations. Key solutions include the use of "volatile" for variable declaration, mutexes, and semaphores to manage access to shared data. Participants highlight the importance of efficient algorithm design to minimize synchronization overhead and suggest prioritizing threads for tasks like SD card read/write operations. The conversation also references FreeRTOS as a critical component for managing tasks on the ESP-32.
Generated by the language model.
Today's popular

FAQ

TL;DR: On ESP32, over‑synchronisation can waste ~50% CPU; "volatile is not a cure." Use FreeRTOS mutexes/semaphores and plan minimal contention. [Elektroda, PrawieElektronik, post #19782858]

Why it matters: This FAQ helps ESP32 developers share variables safely across two cores while maintaining SD‑card I/O and responsiveness.

Quick Facts

How do I safely share variables between ESP32 cores?

Protect each shared variable with a FreeRTOS mutex. Take the lock before reading or writing, and release it immediately after. Keep critical sections short to avoid blocking the other core. This prevents torn reads and inconsistent states. Use this pattern for any data that both cores touch. [Elektroda, khoam, post #19784946]

Is volatile enough for cross‑core variables on ESP32?

No. Volatile only prevents register caching. It does not make access atomic or coordinate readers and writers. You can still get races and inconsistent reads. As one expert put it, “volatile is not a cure.” Use proper synchronisation instead. [Elektroda, PrawieElektronik, post #19782858]

What’s the fastest way to sync shared data in ESP‑IDF?

Reduce how often you need to sync. Process data in blocks and treat completed blocks as immutable. Pass whole blocks between tasks rather than sharing live state. This cuts lock time and contention. Good structure beats clever locking tricks. [Elektroda, JacekCz, post #19801147]

Mutex vs semaphore in FreeRTOS—what should I use?

Use a mutex to protect a resource that only one task should own. Mutexes include priority inheritance to reduce priority inversion. Use a binary semaphore for signaling events rather than ownership. Counting semaphores manage N permits. Keep lock durations short regardless of choice. [Barry, 2016]

How should I structure SD card read/write while keeping the app responsive?

Run SD card I/O in its own high‑priority task. Keep each pass short to minimise blocking. Favour small, quick operations so other tasks can run between calls. Keep other work at lower priority. This preserves throughput and responsiveness. [Elektroda, khoam, post #19800415]

How much CPU can locking cost on ESP32?

It can be significant if used everywhere. One contributor warns synchronisation can burn even 50% of a core. Minimise lock usage and keep critical sections brief. Profile hotspots and refactor shared paths to reduce contention. [Elektroda, PrawieElektronik, post #19782858]

What’s a minimal‑contention pattern for dual‑core sharing?

Partition work into blocks and treat finished blocks as immutable. Hand off block references between tasks instead of editing shared state. This reduces lock time and prevents cores from stepping on each other’s toes. Layer code to keep shared surfaces small. [Elektroda, JacekCz, post #19801147]

Should I use atomic operations, and when?

Consider atomics for simple flags or counters that change independently. For multi‑field updates or coordinated state changes, use a mutex or semaphore. Atomics complement, but do not replace, higher‑level synchronisation. [Elektroda, freebsd, post #19782267]

Any quick steps to add a FreeRTOS mutex in ESP‑IDF?

  1. Create a mutex once at init (xSemaphoreCreateMutex) and store the handle.
  2. Before touching shared data, call xSemaphoreTake(mutex, timeout).
  3. After finishing, call xSemaphoreGive(mutex). [Barry, 2016]

Can I just let one core read while the other writes?

No. Readers can see half‑updated values and inconsistent states. Your concern is valid. “Very good intuition.” Use atomic operations for simple cases, or guard access with a mutex. Define clear ownership so readers never see partial writes. [Elektroda, freebsd, post #19782267]

What about priority inversion when using mutexes?

Priority inversion happens when a low‑priority task holds a lock needed by a high‑priority task. Use FreeRTOS mutexes, which enable priority inheritance to mitigate this. Avoid guarding resources with plain binary semaphores. Keep critical sections short to further reduce risk. [Barry, 2016]

Is Rust worth considering for safer concurrency on ESP32?

Yes, for stronger safety. Rust’s ownership rules prevent many data races at compile time. As one expert said, it’s “worth taking an interest” for concurrent programming. Expect a learning curve and evolving ESP32 support. Start small with FFI or IDF bindings. [Elektroda, freebsd, post #19782267]
Generated by the language model.
ADVERTISEMENT