SirSydom
Posts: 28
Joined: Mon Jan 18, 2021 7:38 am

Is it safe to call different member functions of one objects from different cores?

Fri Sep 17, 2021 8:27 am

Hi,

I want so share data between the 2 cores.

Is it safe to call SetData from one, GetData from the other core?
It would be realizied by a global instance of DataExchange.

Simplified pseudo code to show what I want to do:

Code: Select all

class DataExchange
{
	int data;
	
	int GetData()
	{
		int retval;
		mutex_enter_blocking();
		retval = data;
		mutex_exit();
		return retval;
	}
	
	void SetData(int newdata)
	{
		mutex_enter_blocking();
		data = newdata;
		mutex_exit();
	}
}

PiGraham
Posts: 4861
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Is it safe to call different member functions of one objects from different cores?

Fri Sep 17, 2021 12:53 pm

If you literally only need to pass one int value between cores you don't need a mutex. The write and read will be atomic. It's where you pass data that spans multiple cycles that you risk reading part way through a write. I don't know the detail but I'm sure the two cores accessing shared memory must be arbitrated for single cycle read or write.

It looks like you will have one core or the other stuck waiting for the mutex, which is probably not what you want.
It might be better to use a FIFO to pass data between cores. Then each core can be usefully employed most of the time.

SirSydom
Posts: 28
Joined: Mon Jan 18, 2021 7:38 am

Re: Is it safe to call different member functions of one objects from different cores?

Fri Sep 17, 2021 2:18 pm

It's a simple producer-consumer thing. Core0 runs my communication stack with hard timings.
Core1 aquires data ober I2C and so on.
So it is no problem if core1 waits some microseconds unti it can write data.

I think is a lot simpler to solve that with a mutex instead of fifo - I don't care about old values.

You are sure that assignments of by-values types (up to 32bit ?) are atomic?

kilograham
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 958
Joined: Fri Apr 12, 2019 11:00 am
Location: austin tx

Re: Is it safe to call different member functions of one objects from different cores?

Fri Sep 17, 2021 3:18 pm

SirSydom wrote:
Fri Sep 17, 2021 2:18 pm
It's a simple producer-consumer thing. Core0 runs my communication stack with hard timings.
Core1 aquires data ober I2C and so on.
So it is no problem if core1 waits some microseconds unti it can write data.

I think is a lot simpler to solve that with a mutex instead of fifo - I don't care about old values.

You are sure that assignments of by-values types (up to 32bit ?) are atomic?
a 32 bit write is atomic, however that obviously doesn't stop you overwriting the previous value b4 the receiver has read it.
There is always https://github.com/raspberrypi/pico-sdk ... il/queue.h then you don't have to worry about it

SirSydom
Posts: 28
Joined: Mon Jan 18, 2021 7:38 am

Re: Is it safe to call different member functions of one objects from different cores?

Fri Sep 17, 2021 4:02 pm

kilograham wrote:
Fri Sep 17, 2021 3:18 pm
, however that obviously doesn't stop you overwriting the previous value b4 the receiver has read it.
For my current application thats exactly the way it SHOULD work.
If there is a newer sensor value, the old sensor value (if the receiver has read it or not) is not needed anymore.

at the moment I'm protecting the assignment of some floats like shown in the first post.
I assume in that case I can get rid of the mutexes ?

cleverca22
Posts: 4662
Joined: Sat Aug 18, 2012 2:33 pm

Re: Is it safe to call different member functions of one objects from different cores?

Fri Sep 17, 2021 4:07 pm

SirSydom wrote:
Fri Sep 17, 2021 4:02 pm
at the moment I'm protecting the assignment of some floats like shown in the first post.
I assume in that case I can get rid of the mutexes ?
i believe float is 32bit still, and should be safe

but double is 64bit, and will have problems with non-atomic updates

you can confirm that by printing the sizeof() your numbers

PiGraham
Posts: 4861
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Is it safe to call different member functions of one objects from different cores?

Fri Sep 17, 2021 6:59 pm

The code posted was int:

Code: Select all

int data;

mschnell
Posts: 70
Joined: Wed Jul 28, 2021 10:33 am
Location: Krefeld, Germany

Re: Is it safe to call different member functions of one objects from different cores?

Sat Sep 18, 2021 10:49 am

Regarding concurrent access, the object structure is completely irrelevant. You can consider member function just like completely unrelated functions that just happen to be easily able to access the same data structure.
Hence the clear answer is "NO", you need to make sure to force atomic access via "atomic" functions or by decent othger decent means.
"float" is not secure at all, as the M0+ hardware even does not know that something like that exists.
-Michael

lurk101
Posts: 965
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

Re: Is it safe to call different member functions of one objects from different cores?

Sun Sep 19, 2021 1:35 am

mschnell wrote:
Sat Sep 18, 2021 10:49 am
"float" is not secure at all, as the M0+ hardware even does not know that something like that exists.
-Michael
Incorrect! Even though the CM0+ doesn't have float or double op codes and GCC handles those using function calls to emulate float and double operations, it nevertheless stores and loads float variables to and from memory using single 32 register LDR and STR instructions which ARE naturally atomic on the CM0+. Doubles require 2 consecutive instructions and are not atomic.

mschnell
Posts: 70
Joined: Wed Jul 28, 2021 10:33 am
Location: Krefeld, Germany

Re: Is it safe to call different member functions of one objects from different cores?

Sun Sep 19, 2021 12:39 pm

You can't know this unless you see the code the compiler generates. It could call a function that returns a 32 bit word or it could call a function that takes a pointer to a 32 bit word. in the (unlikely) second case the ROM function could write a single byte (e.g. the exponent) independently of the other three.
Moreover the line
x += 1;
is not atmic, be that float or an int32_t, unless you use some "atomic_inc" macro,.
I'm not sure with the M0+, but AFAIK ARM cores do feature block lock instructions that (e.g.) allow for writing multiple words as an atomic operation.
-Michael

lurk101
Posts: 965
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

Re: Is it safe to call different member functions of one objects from different cores?

Sun Sep 19, 2021 3:34 pm

mschnell wrote:
Sun Sep 19, 2021 12:39 pm
You can't know this unless you see the code the compiler generates.
I looked at what the compiler generates.
It could call a function that returns a 32 bit word or it could call a function that takes a pointer to a 32 bit word. in the (unlikely) second case the ROM function could write a single byte (e.g. the exponent) independently of the other three.
No idea what you're trying to say...

Moreover the line
x += 1;
is not atmic...
I wouldn't expect that to be atomic, because it's a load-modify-store construct. I think we have a different understanding of what atomic means. An atomic operation is an operation that will always be executed without any other process being able to read or change state that is read or changed during the operation. At the machine level I define 'operation' as meaning a machine instruction.

On CM0 loading or storing a float generates a single instruction thus is atomic. Loading or storing a double requires two instructions therefore is not atomic. Same for int and long long int.

Higher level languages like C++ support generalized atomic objects, but my interpretation applies to the OP's case where one thread simply stores a float or int variable while another thread tries to read it.

Note that even in C++, no special action is taken for atomic 32 bit value loads and stores.

Code: Select all

atomic<int> i;
i = 123;
int j = i;
will compile to simple single LDR and STR instruction enclosed in memory barriers. No need for anything else since those are naturally atomic.

Return to “SDK”