CCB: Changed logic of work using boost conditional variable

[LitvinenkoIra]

Bug Report

Data races related to Logger

Detailed analysis:

Note that the same mutex is locked before the shared data is updated,
but that mutex does not have to be locked across the call to notify_one.:
https://www.boost.org/doc/libs/1_66_0/doc/html/thread/synchronization.html#thread.synchronization.condvar_ref

In function Thread::threadFunc

thread->run_lock_.Acquire();
sync_primitives::AutoLock auto_lock(thread->state_lock_);
thread->run_lock_.Release();

This is not a lock for acquiring another lock.
This code part ensures correct notification sequence between Thread::start and threadFunc.
In Thread::start function after thread is created, we call Wait(),
but we cannot guarantee order of precedence of the following calls :
"Wait() in Thread::start" or "Broadcast in threadFunc".
sync_primitives::AutoLock auto_lock(thread->run_lock_); - is used to
guarantee call to "Wait() in Thread::start" before Broadcast.

Reproduction Steps

1. TBD

Expected Behavior

SDL should not crash

Observed Behavior

SDL crashed

OS & Version Information

• OS/Version : SYNC4
• SDL Core Version: https://github.com/smartdevicelink/sdl_core/releases/tag/5.0.1
• Testing Against: SYNC4 Applink

[SNiukalov]

After merge #3471 we do not use multiple conditional variable or lockable objects for guarantee order of precedence of the following calls :
"Wait() in Thread::Start, Stop and Join" or "Broadcast in threadFunc".

In the current implementation, we use a single instance for a conditional variable and a lockable object.

After merge #3471 all regression tests are passed.
So I believe it is redundant for the current implementation.

[LitvinenkoIra]

@theresalech we believe that this issue already fixed by #3471

[theresalech]

@LitvinenkoIra thank you for letting us know! We will review as time allows before the Core 7.0 release.

[iCollin]

Closed via #3471