Improvement #275

Improve WaitForCommand triaging

Added by Philipp Buluschek almost 4 years ago. Updated almost 4 years ago.

Status:Rejected Start date:11/12/2014
Priority:Normal Due date:
Assignee:Stefano Lenzi % Done:


Category:zigbee.CC2530.driver Spent time: -
Target version:org.aaloa.zb4osgi.zigbee.CC2530.driver-0.3.0
Has a patch:No Has license agreement signed:No


Diverse commands use the WaitForCommand waiter to be notified when an async response arrives. As these are asynchronous, they may arrive at any time (within the TIMEOUT). Also, as the system is multithreaded, several WaitForCommand may be registered at the same time.

The current triage only takes into account the command which we wait for. This is not enough to do it correctly. For example, if you send an IEEE_ADDR_REQ to 2 different devices, any of the two responses which arrive first will be assigned to the first request. For it to work correctly, we must also check in the waiter whether the source address is the device we expect to answer.

If we don't, the problem might be quite severe: for example LQINetworkBrowserThread uses the sending address but the returned IEEE to build the internal ZigBeeNodeImpl. This may result in a wrong mapping between network address and IEEE.

Other requests cannot use the source address, but provide a transaction number instead. For example, AF_DATA_REQUEST waits for a AF_DATA_CONFIRM. Both of these have transaction IDs which must be checked... (but I guess the source address cannot be used, if there is only a MAC_ACK).

Related issues

related to Bug #277: Deadlock when multiple thread try to send the same request Closed 11/13/2014

Associated revisions

Revision 1094
Added by Stefano Lenzi almost 4 years ago

Extracted WaitForAList and WaitForCommand as class so that code reasue among different driver is easier ( refs #275 )

Revision 1097
Added by Stefano Lenzi almost 4 years ago

WaitForCommand throws and exception when it fails to store itself as listener ( refs #275 )


#1 Updated by Stefano Lenzi almost 4 years ago

  • Tracker changed from Task to Improvement
  • Category set to zigbee.CC2530.driver
  • Status changed from New to In Progress
  • Assignee set to Stefano Lenzi
  • Target version set to org.aaloa.zb4osgi.zigbee.CC2530.driver-1.X
  • Has a patch set to No
  • Has license agreement signed set to No

I don't think it is an issue for the current implementation because all the drivers should avoid that multiple WaitForCommand are executed at the same time, but I have to check the code and provide a JUnit for it.

In case this issue will affect all the following modules:
  • zigbee.cc2480.datatlink
  • zigbee.CC2530.driver
  • zigbee.ez430-rf2480.driver

#2 Updated by Stefano Lenzi almost 4 years ago

  • Status changed from In Progress to Rejected

Result Summary

I have reviewed the code and I think that the issue reported is not affecting the current implementations. I could not create any simple JUnit that could prove or deny the issue. Moreover, the code review lead to the discovery of the bug #277

Code Analysis

By reviewing the code I realized that the multi-thread scenario is not affecting any ZIC implementation at the moment (namely the zigbeee.CC2530.driver and the zigbee.ez430-rf2480.driver) because when we designed the driver we have already been aware that the WaitForCommand cannot be enough for matching request / response when they belong to the same type (i.e. multiple sendZDOIEEEAddressRequest() was invoked by different thread), thus we defined that multiple request of the same time get serialized.
The current implementations of the ZIC will serialize the request if they are the same-type-of-request otherwise they will go in parallel.


Please consider the following scenario where all the Thread are using the same instance of the CC2530Driver class
  • Thread A: send ZDO_IEEE_ADDR_REQ
  • Thread B: send ZDO_MGMT_LQI_REQ
  • Thread C: send ZDO_IEEE_ADDR_REQ

as result the CC2530Driver will perform ZDO_IEEE_ADDR_REQ from Thread A and ZDO_MGMT_LQI_REQ from Thread B in parallel, while it will put on hold the Thread C because it is trying to send the same-type-of-request of Thread A, when Thread A then Thread C will be awaken and it will perform its ZDO_IEEE_ADDR_REQ

Serialization process

The serialization is achieved by wrapping all the communication that require a WaitForCommand with the waitAndLock3WayConversation and unLock3WayConversation


If you think that it is not enough or more that some communication are not wrapped as described please reopen this issue.

#3 Updated by Stefano Lenzi almost 4 years ago

  • Target version changed from org.aaloa.zb4osgi.zigbee.CC2530.driver-1.X to org.aaloa.zb4osgi.zigbee.CC2530.driver-0.3.0

Also available in: Atom PDF