Commit eaab0406 authored by Jeffrey Lee's avatar Jeffrey Lee
Browse files

Fix a couple of spinrw issues

  s/spinrw - Add a barrier to the Pause macro to prevent excessive spinning when multiple cores are competing for the same lock.
  Also, fix garbage pointer being passed to OS_UpCall by spinrw_write_sleep_lock
  Tested on Raspberry Pi 3

Version 0.04. Tagged as 'SyncLib-0_04'
parent eb3ebf01
/* (0.03)
/* (0.04)
* This file is automatically maintained by srccommit, do not edit manually.
* Last processed by srccommit version: 1.1.
#define Module_MajorVersion_CMHG 0.03
#define Module_MajorVersion_CMHG 0.04
#define Module_MinorVersion_CMHG
#define Module_Date_CMHG 08 May 2016
#define Module_Date_CMHG 06 Jun 2017
#define Module_MajorVersion "0.03"
#define Module_Version 3
#define Module_MajorVersion "0.04"
#define Module_Version 4
#define Module_MinorVersion ""
#define Module_Date "08 May 2016"
#define Module_Date "06 Jun 2017"
#define Module_ApplicationDate "08-May-16"
#define Module_ApplicationDate "06-Jun-17"
#define Module_ComponentName "SyncLib"
#define Module_ComponentPath "bsd/RiscOS/Sources/Lib/SyncLib"
#define Module_FullVersion "0.03"
#define Module_HelpVersion "0.03 (08 May 2016)"
#define Module_LibraryVersionInfo "0:3"
#define Module_FullVersion "0.04"
#define Module_HelpVersion "0.04 (06 Jun 2017)"
#define Module_LibraryVersionInfo "0:4"
......@@ -201,6 +201,19 @@ $label Pause
MOV r0, r0
MOV r0, r0
; Make sure any important pending writes are flushed before we go to sleep (the
; write buffer may not drain while we're asleep). This is significant because
; we only use Pause after a failed lock attempt; we need to make sure the
; MetaUnlock is flushed otherwise the owner of the spinrw may become stuck
; on MetaLock when he tries to release the spinrw. (This behaviour has been
; observed on Cortex-A53)
; For other cases we assume the MetaUnlock will be flushed naturally within a
; reasonable timeframe. However, spending some time doing some experimentation
; and benchmarking would be wise.
; If natural flushing is proven to take too long, it might be wise to move all
; the barrier and CPUEventSend calls to just before the PSR is restored, to
; make sure a pending IRQ doesn't cause them to be subjected to an extra delay.
......@@ -274,8 +287,8 @@ spinrw_write_sleep_lock_$variant ROUT
MetaUnlock a2, a3
Push "r0"
MOV r0, #6
ADR r1, Pollword
MOV r0, #6
Pull "r0"
B %BA10
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment