tree 6968356f8a773a11b1ba1476adbd3e14b969d087
parent 8e2dd5b861fd15a73ec85521470aa9709c668e1e
author Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com> 1641446041 -0800
committer GitHub <noreply@github.com> 1641446041 -0800
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJh1nqZCRBK7hj4Ov3rIwAASLgIAFUT84Z7LT9aNqPMqyEFYvdV
 NSh7JcdCA4TJW7d7ov02MHz8g264XIXesNgnBDfs62V6+Q3S/mD2dM5angk393rF
 ctKtDnxzRCk50ifpxsHnaFDJ+H1tKVNXEJ8ZZbTqn5OWoFWj0lW+ldb8ZZoFEym7
 ae7c1ERrX26kkweIDvEZZkJGOw5apSaAyzivnimqFXdbbkz21JQpbXBfbqkiNoMi
 vYO1SGbDjGGzmaIOnqANB8JtU6i1Md+JtaZDyMRqI80KQLkshHI1r4yAHkMq4KGu
 b3dPj1Y9Y17JzYieAObJDtApXoX5fAPNAH0lkS5avKkmt6w3yFpCA4OYiStjQxs=
 =lolL
 -----END PGP SIGNATURE-----
 

Add a cap to the queue locks (#435)

Add a cap to the queue locks

cRxLock and cTxLock members of the queue data structure count the
number items received and sent to the queue while the queue was locked.
These are later used to unblock tasks waiting on the queue when the
queue is unlocked. The data type of these members is int8_t and this can
trigger overflow check assert if an ISR continuously reads/writes to the
queue in a loop as reported in this issue: https://github.com/FreeRTOS/FreeRTOS-Kernel/issues/419. 

Note due to the length of the operation is it not recommended to write to
the queue that many times from an ISR - stream buffers are a better option,
or alternatively, defer the operation to a task by just having the ISR send a
direct to task notification to unblock the task.

This PR caps the values of the cRxLock and cTxLock to the number of tasks in
the system because we cannot unblocks more tasks than there are in the system. 
Note that the same assert could still be triggered is the application creates more
than 127 tasks.

Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>