On 12/14/24 17:06, Bertho Stultiens wrote:
On 12/14/24 10:57 PM, andy pugh wrote:
Probably done as an "it should not hurt" effort. However, using
volatile
on shared variables in a multi-threaded context is wrong, plain and
simple, and therefore actually harmful.
Is our realtime layer multithr
On 12/14/24 10:57 PM, andy pugh wrote:
Probably done as an "it should not hurt" effort. However, using volatile
on shared variables in a multi-threaded context is wrong, plain and
simple, and therefore actually harmful.
Is our realtime layer multithreaded? I have always thought that it was
delib
On Sat, 14 Dec 2024 at 19:37, Bertho Stultiens wrote:
> Probably done as an "it should not hurt" effort. However, using volatile
> on shared variables in a multi-threaded context is wrong, plain and
> simple, and therefore actually harmful.
Is our realtime layer multithreaded? I have always thou
On 12/14/24 7:31 PM, andy pugh wrote:
HAL processes run in strict sequence, so most realtime components
probably don't access the same memory at the same time.
The exceptions are where there are both base threads and a servo
thread, and possibly where there is access to HAL pins from user-space
HAL processes run in strict sequence, so most realtime components
probably don't access the same memory at the same time.
The exceptions are where there are both base threads and a servo
thread, and possibly where there is access to HAL pins from user-space
(and, maybe from the G-code (but I think
On 12/2/24 13:37, Nicklas SB Karlsson wrote:
There is no volatile cast so will also cast type and then there is a
possibility to by misstake cast to wrong type.
Casting is inherently a dangerous operation.
If parameter is passed by value create a local variable with volatile
modifier and assi
mån 2024-12-02 klockan 12:18 +0100 skrev Robert Schöftner:
> Am Sonntag, dem 01.12.2024 um 12:41 +0100 schrieb Bertho Stultiens:
> > On 11/30/24 03:28, Curtis Dutton wrote:
> > > I wrote the initial hal port code. there is no reason that I know
> > > of
> > > why it is required. I was following wh
Am Sonntag, dem 01.12.2024 um 12:41 +0100 schrieb Bertho Stultiens:
> On 11/30/24 03:28, Curtis Dutton wrote:
> > I wrote the initial hal port code. there is no reason that I know
> > of
> > why it is required. I was following what I saw in other hal code
> > without really knowing if it was neede
On 12/1/24 13:47, Nicklas SB Karlsson wrote:
There should be a review to look into the other instances of volatile.
I've seen the use of some atomics/memory barriers in the code, but there
are many pointers used where volatile changes the code's load/store
behavior, which may be essential for sha
sön 2024-12-01 klockan 12:41 +0100 skrev Bertho Stultiens:
> On 11/30/24 03:28, Curtis Dutton wrote:
> > I wrote the initial hal port code. there is no reason that I know of
> > why it is required. I was following what I saw in other hal code
> > without really knowing if it was needed. > Rip it o
On 11/30/24 03:28, Curtis Dutton wrote:
I wrote the initial hal port code. there is no reason that I know of
why it is required. I was following what I saw in other hal code
without really knowing if it was needed. > Rip it out!
Done. See PR#3199 for details.
Not all instances of volatile are
I wrote the initial hal port code. there is no reason that I know of why it
is required. I was following what I saw in other hal code without really
knowing if it was needed.
Rip it out!
If the tests pass it's probably fine. I run components daily that depends
upon hal_port so I'll catch it (and
Hi,
The C++20 standard has deprecated a lot of volatile use. Therefore, a
lot of warnings pop-up in the compile, especially in hal/hal.h:
warning: ‘volatile’-qualified parameter is deprecated [-Wvolatile]
in lines 869, 879, 890, 900, 905,910, 915, 921
Same warning in hal/hal_priv.h:489.
The
13 matches
Mail list logo
