From 63b3ea113fdeca4b51bf68fec23354e6a78fafae Mon Sep 17 00:00:00 2001 From: "R. Steve McKown" Date: Fri, 24 Sep 2010 16:32:11 -0600 Subject: [PATCH] Race condition clearing bit vectors that are already clear in Init.init. There's no point to clear the bit vectors in SharedArbiterP.Init.init, because the compiler guarantees they are already clear, see BitVectorC.nc. However, manually clearing them can create a situation where someone requesting a shared resource has their requesting bit erased, depending upon the order of calls to Init.init providers during boot. --- tos/system/SharedArbiterC.nc | 3 --- tos/system/SharedArbiterP.nc | 8 -------- 2 files changed, 11 deletions(-) diff --git a/tos/system/SharedArbiterC.nc b/tos/system/SharedArbiterC.nc index 8d1b618b..19499784 100644 --- a/tos/system/SharedArbiterC.nc +++ b/tos/system/SharedArbiterC.nc @@ -50,9 +50,6 @@ implementation { ResourceDefaultOwner = SharedArbiterP; ArbiterInfo = SharedArbiterP; - components MainC; - MainC.SoftwareInit -> SharedArbiterP; - components new BitVectorC(CLIENTS) as GrantedVectorC; SharedArbiterP.GrantedVector -> GrantedVectorC; diff --git a/tos/system/SharedArbiterP.nc b/tos/system/SharedArbiterP.nc index aa926069..40afb970 100644 --- a/tos/system/SharedArbiterP.nc +++ b/tos/system/SharedArbiterP.nc @@ -38,7 +38,6 @@ generic module SharedArbiterP() { provides { - interface Init; interface Resource[uint8_t id]; interface ResourceDefaultOwner; interface ArbiterInfo; @@ -117,13 +116,6 @@ implementation { } } - command error_t Init.init() - { - call GrantedVector.clearAll(); - call RequestingVector.clearAll(); - return SUCCESS; - } - async command error_t Resource.request[uint8_t id]() { /* The Resource docs do not say what happens when a user calls -- 2.39.2