atomic.h vs cli and sei

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've noticed that atomic.h uses cli() and sei() both with and without explicit memory barriers.

IIRC when atomic.h was new, cli() and sei() did not have their own memory barriers.

Perhaps atomic.h should be edited to use explicit inline assembly instead of the cli() and sei() macros.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You probably want to contact Dean directly. I remember at the time him mentioning the possibility of code re-ordering and how he thought his usage would be safe but, off hand, I cannot remember the reason given. Nothing like hearing it from the horses mouth!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually, when I wrote the above, I was thinking that there would be extraneous memory barriers.

Now, I'm not sure that it was originally guaranteed to work.

 

For example, it seems to me that the force-on scenario is equivalent to

cli(); // originally, no barrier
_MemoryBarrier()
stuff()
sei(); // originally, no barrier

The problem is that previously the cli() and sei() could have still been moved pretty much arbitrarily.

Now that cli() and sei() have built-in barriers, atomic.h should work as advertised.

So would

cli();
stuff();
sei();

That said, if stuff() has multiple exits, the mechanism to ensure that interrupts are re-enabled could avoid a long debugging session.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

just curious,

what would the additional "_memoryBarrier()" do?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0