mechanism to orchestrate concurrent executions of threads that work for screen connector
One thing is when any of wayland/socket-based connector or confirmation UI has a frame, it should wake up the consumer The two queues are separate, so the conditional variables, etc, can't be in the queue
void cuttlefish::ScreenConnectorCtrl::WaitAndroidMode |
( |
| ) |
|
|
inline |
The thread that enqueues Android frames will call this to wait until the mode is kAndroidMode
Logically, using atomic_mode_ alone is not sufficient. Using mutex alone is logically complete but slow.
Note that most of the time, the mode is kAndroidMode. Also, note that this method is called at every single frame.
As an optimization, we check atomic_mode_ first. If failed, we wait for kAndroidMode with mutex-based lock
The actual synchronization is not at the and_mode_cv_.wait line but at this line: if (atomic_mode_ == ModeType::kAndroidMode) {
This trick reduces the flag checking delays by 70+% on a Gentoo based amd64 desktop, with Linux 5.10