Handle race condition and mutex issues. 83/211883/1
authorSenthil Kumar G S <senthil.gs@samsung.com>
Thu, 8 Aug 2019 09:38:07 +0000 (15:08 +0530)
committerSudipto Bal <sudipto.bal@samsung.com>
Fri, 9 Aug 2019 13:54:01 +0000 (13:54 +0000)
commit7fc8a30b5d0054190578c81ae8d598c58a40139c
treec30d81cbb1d550145741e53aeff4909fc8053396
parent030ddb9a13a5589a5066b35b1a5b7b1e09b0f99f
Handle race condition and mutex issues.

NSStopConsumer() results in crash at NSDestroyQueue().
As per the crash log, after consumer message handler thread (NSConsumerMsgHandleThreadFunc) comes to an end,
there seems to be a race condition between the thread which called NSStopConsumer() and another thread which calls NSConsumerMsgPushThreadFunc().
Both threads try to access the message queue. One enqueues and another dequeues which could result in undefined behaviour.
Handled it by checking the running status of message handler thread before enqueuing request.

Another issue in with improper access of "g_create_mutex" in NSThread.c.
There is a chance that NSThreadInit could initialize the same mutex multiple times.
And NSDestroyThreadHandle unlocks the mutex without locking it. (NSThreadInit & NSDestroyThreadHandle are called
from several threads and the way they access the mutex could result in undefined behavior).
As the usage and the main intention of the mutex is not clear, removed it.

https://github.sec.samsung.net/RS7-IOTIVITY/IoTivity/pull/554/commits/93e66a00acc08ce0c7a3fb217bfb2cc92f2a6c15
(cherry-picked from 93e66a00acc08ce0c7a3fb217bfb2cc92f2a6c15)

Change-Id: Iaa11c9b9b0088d4626cc92f85bbb55fb69f417af
Signed-off-by: Senthil Kumar G S <senthil.gs@samsung.com>
Signed-off-by: Sudipto <sudipto.bal@samsung.com>
service/notification/src/consumer/NSConsumerScheduler.c
service/notification/src/consumer/NSThread.c