#205 Shouldn't __sync_synchronize() be used after writes and before IO reads ?

[David Rayna]

Unless all CPUs do not queue writes or use caching for the gpio memory, shouldn't something like this be used, especially on multiple core CPUs ?

void output_gpio(int gpio, int value)
{
    int offset, shift;

    if (value) // value == HIGH
        offset = SET_OFFSET + (gpio/32);
    else       // value == LOW
       offset = CLR_OFFSET + (gpio/32);

    shift = (gpio%32);

    *(gpio_map+offset) = 1 << shift;
   __sync_synchronize();  // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
}

int input_gpio(int gpio)
{
   int offset, value, mask;

   offset = PINLEVEL_OFFSET + (gpio/32);
   mask = (1 << gpio%32);
   __sync_synchronize();  // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
   value = *(gpio_map+offset) & mask;
   return value;
}

[David Rayna]

Within a single Python program, there should be little issue, but would
other processes or external hardware always see bits tested and changed in
the same order?
I no longer have an issue of wrong GPIO changing among simultaneous C++ &
Python programs since I corrected a C++ code mistake in using the special
set & clear addresses in the gpio_map.
I had seen some examples of C GPIO code using __sync_synchronize() so I was
thinking there was a concern.
CPU behavior or overhead in Python might assure consecutive IO operations
are never reordered at run time.
It is possible that gpio_map is excluded from any low-level caching.

On Sat, Sep 24, 2022 at 6:23 AM Ben Croston croston@users.sourceforge.net
wrote:

• assigned_to: Ben Croston
• Comment:

CPython effectively operates as a single thread (i.e. it uses the GIL) so
this is unlikely to be a problem. Do you know of any issues that the lack
of __sync_synchronize() causes?

---

• [tickets:#205]
  https://sourceforge.net/p/raspberry-gpio-python/tickets/205/ Shouldn't
  __sync_synchronize() be used after writes and before IO reads ?*

Status: New
Created: Thu Aug 25, 2022 07:31 PM UTC by David Rayna
Last Updated: Thu Aug 25, 2022 07:31 PM UTC
Owner: Ben Croston

Unless all CPUs do not queue writes or use caching for the gpio memory,
shouldn't something like this be used, especially on multiple core CPUs ?

void output_gpio(int gpio, int value)
{
int offset, shift;

if (value) // value == HIGH
    offset = SET_OFFSET + (gpio/32);
else       // value == LOW
   offset = CLR_OFFSET + (gpio/32);

shift = (gpio%32);

*(gpio_map+offset) = 1 << shift;

__sync_synchronize(); // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
}
int input_gpio(int gpio)
{
int offset, value, mask;

offset = PINLEVEL_OFFSET + (gpio/32);
mask = (1 << gpio%32);
__sync_synchronize(); // <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
value = *(gpio_map+offset) & mask;
return value;
}

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/raspberry-gpio-python/tickets/205/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Ben Croston]

CPython effectively operates as a single thread (i.e. it uses the GIL) so this is unlikely to be a problem. Do you know of any issues that the lack of __sync_synchronize() causes?