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.

diff --git a/tos/system/SharedArbiterC.nc b/tos/system/SharedArbiterC.nc
index 8d1b618bd7646c157e3a1d94620ef3f8032a3a82..19499784d2aab12f8d9a73b64d3e3e07c6bb2222 100644 (file)
--- 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 aa9260693c5d39fc3c5205031034f3059885e699..40afb970ed91b670578ba4091ac385d323eb3115 100644 (file)
--- 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