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.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 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.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

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

just curious,

what would the additional "_memoryBarrier()" do?

 

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