4

I have implemented a mutex on an embedded system that have armv7 processor and a basic scheduler

There are several instructions in armv7 instruction set that are used for power efficiency.

Two of these instructions are WFE (wait for event) and WFI (wait for interrupt), the instructions enter the processor to idle mode until an event is raised or an interrupt is raised,accordingly.

Also the processor will exit idle mode if the condition that accompanied the instruction is true.

I could use one to these instructions when i failed to acquire the mutex thus the processor will be idle through the remaining of the time slice until a timer interrupt is raised and then the scheduler will context switch to another task.

If i am not concerned with power consumption is there really a reason to use these instructions instead of busy looping?

omer12433
  • 51
  • 7
  • 1
    Are you talking about a multi-core system? Otherwise, I don't understand how either busy-looping or idling the CPU can be of any use; how is someone else going to release the lock if you hog the CPU with a busy loop or send it to sleep? – Jörg W Mittag Apr 15 '17 at 11:17
  • @JörgWMittag even on a single core the cpu will be idle untill a timer interrupt is raised and the processor will exit idle mode and the scheduler will context switch to another task – omer12433 Apr 15 '17 at 11:18
  • Ah, you mean giving up the rest of the timeslice until the scheduler kicks in? Yeah, that makes more sense, thanks for clearing that up. Somehow, I was thinking about a cooperative threading system; I missed the part about having a scheduler, which obviously implies a preemptive system. Sorry for the mixup. – Jörg W Mittag Apr 15 '17 at 11:21
  • @JörgWMittag the mentioned task doesn't give up the rest of the time slice but entering the processor to idle mode untill the time slice is over – omer12433 Apr 15 '17 at 11:28
  • Yes, sorry, that's what I meant. "Waiting out the rest of the timeslice" would have been a better way to phrase it. I didn't mean "give up" in the sense of giving it to another task, but rather in the sense of not doing anything with it. – Jörg W Mittag Apr 15 '17 at 11:32
  • As long as there is a reasonable limit to the spin wait you should have no problem. – Frank Hileman Apr 15 '17 at 19:54
  • @FrankHileman I know both ways will work what i am asking that is there a reason to use the wfe or wfi instruction instead of busy looping – omer12433 Apr 15 '17 at 21:03
  • I am no expert so I suggest you consult a forum specific to the architecture and assembly coding. However, based on the documentation, it sounds as if these are processor wide (machine wide) instructions. Are you implementing the operating system? It seems to me these instructions would be used if there are no "other tasks", so it is something only used by the operating system. – Frank Hileman Apr 17 '17 at 16:22
  • @FrankHileman it's a theoretical question about implementation of mutex in an arm based system if i were to implement an operating system – omer12433 Apr 17 '17 at 16:35
  • Ok I think you have a good idea there. You could spin first then use one of the instructions -- that is, if there is nothing waiting to run. However I am only speaking in general terms as I am not an expert on the architecture. – Frank Hileman Apr 17 '17 at 22:50
  • Concomitant with power saving, which is discounted, there is thermal budget which might come into play depending on HW design, enclosure design, and frequency/duration of wait on mutexes. Otherwise, I can't see a compelling argument to keep you from spinning. – CuriousRabbit Apr 20 '17 at 22:25

2 Answers2

1

No. Low-power modes are highly MCU dependent. Among the different silicon suppliers, the following could vary:

  • Which peripherals/clocks are disabled in sleep/deep-sleep mode
  • What is the sequence to wake-up the MCU peripherals/CPU

WFI and WFE instructions have been designed by ARM to synchronize CPU(s) with the other peripherals.

If you are not interested in power saving, then you could just loop, some RTOS such as μc/OS-II even base their statistics on the processing done in the idle task (default loop when CPU is idle in most RTOS).

Jocelyn
  • 21
  • 3
0

Keep in mind that both WFI and WFE suspend CPU, so they both will prevent that CPU from executing other tasks.

If by "mutex" you mean "kernel-level-spinlock", then yes, you can use WFE and SEV instructions to avoid busy looping.

If by "mutex" you mean OS-level primitive that can suspend a "thread" of execution (not a CPU), then you cannot use them directly from a mutex. If thread fails to acquire a mutex, it should add itself to the waiting queue and call kernel scheduler. It is responsibility of the scheduler to execute WFI when there are no tasks to run.

Even if power consumption is not your concern, you might want to think about how busy looping can affect memory bus performance - hogging it with unnecessary reads can slow down other CPUs/hardware accessing the same bus.