Merge lp:~albaguirre/mir/fix-1427976 into lp:mir
Status: | Rejected |
---|---|
Rejected by: | Alberto Aguirre on 2015-03-05 |
Proposed branch: | lp:~albaguirre/mir/fix-1427976 |
Merge into: | lp:mir |
Diff against target: |
363 lines (+162/-23) 5 files modified
src/include/common/mir/semaphore_lock.h (+81/-0) src/server/frontend/session_mediator.cpp (+22/-22) src/server/frontend/session_mediator.h (+2/-1) tests/unit-tests/CMakeLists.txt (+1/-0) tests/unit-tests/test_semaphore_lock.cpp (+56/-0) |
To merge this branch: | bzr merge lp:~albaguirre/mir/fix-1427976 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Alberto Aguirre (community) | Disapprove on 2015-03-05 | ||
Alan Griffiths | Needs Fixing on 2015-03-05 | ||
Alexandros Frantzis (community) | Needs Fixing on 2015-03-05 | ||
Daniel van Vugt | 2015-03-04 | Needs Fixing on 2015-03-05 | |
PS Jenkins bot (community) | continuous-integration | Approve on 2015-03-04 | |
Review via email:
|
Commit message
Avoid unlocking sesssion mutex in a different thread.
In some cases, SessionMediator needs to lock the session
while it waits for Surface:
asynchronously on a different thread. Since a std::mutex
cannot be used for such purposes a SemaphoreLock type is introduced.
Description of the change
Avoid unlocking sesssion mutex in a different thread.
In some cases, SessionMediator needs to lock the session
while it waits for Surface:
asynchronously on a different thread. Since a std::mutex
cannot be used for such purposes a SemaphoreLock type is introduced.
Daniel van Vugt (vanvugt) wrote : | # |
I'm not yet sure what you're trying to express, but Semaphore(Lock) seems like the wrong name.
I recall semaphore as a type of lock with a counter. The counter is the defining feature of a semaphore. And a quick search seems to support this: http://
So I think "Semaphore" is an incorrect name.
Alexandros Frantzis (afrantzis) wrote : | # |
I am OK with the name, perhaps I would slightly prefer BinarySemaphore.
103 - auto const lock = std::make_
104 + SemaphoreUnlock
147 - auto const lock = std::make_
148 + SemaphoreUnlock
The current locking scheme (using shared<
> I recall semaphore as a type of lock with a counter. The counter is the defining feature
> of a semaphore. And a quick search seems to support this:
> http://
From the bottom of the page:
A mutex is essentially the same thing as a binary semaphore and sometimes uses the
same basic implementation ... Mutexes have a concept of an owner. Only the process
that locked the mutex is supposed to unlock it. If the owner is stored by the mutex
this can be verified at runtime.
"Needs fixing" for the less safe locking scheme, looks good otherwise.
Alan Griffiths (alan-griffiths) wrote : | # |
*Needs Discussion*
I wonder whether the better fix is to ensure there is only a single IPC thread running and dispatch all activity to that thread.
Alberto Aguirre (albaguirre) wrote : | # |
> *Needs Discussion*
>
> I wonder whether the better fix is to ensure there is only a single IPC thread
> running and dispatch all activity to that thread.
By default the IPC thread pool is set to 1 but it's configurable option (--ipc-thread-pool)
The other thread involved is the compositor thread, because of the completion given to surface.
Alberto Aguirre (albaguirre) wrote : | # |
So we have three options:
1. Use a BinarySemaphore as proposed here
2. Make SessionMediator
3. Remove the session_mutex all together by removing the --ipc-thread-pool option and doing 2 above (so only a single IPC thread is active at any time)
Alberto Aguirre (albaguirre) wrote : | # |
Well option 2,3 would block the IPC thread, so not good.
Option 4. Schedule IPC responses to the IPC thread that originated them (if we still want an IPC thread pool)
I think we can land this for now (pending addressing Alexandros comments) and then do some refactoring to allow option 4 in a separate MP.
Alan Griffiths (alan-griffiths) wrote : | # |
OK.
Let's go with a variant of this scheme.
Can we avoid the dubious release semantics of SemaphoreUnlock
Alberto Aguirre (albaguirre) wrote : | # |
Well after looking at bit more at the code, it seems like the real reason for the session_mutex unlock in the completion is to avoid holding a lock when invoking IPC callbacks.
Since Surface:
Unmerged revisions
- 2361. By Alberto Aguirre on 2015-03-04
-
Avoid unlocking sesssion mutex in a different thread.
In some cases, SessionMediator needs to lock the session
while it waits for Surface::swap_buffers which may complete asynchronously on a different thread.
Since a std::mutex cannot be used for such purposes a SemaphoreLock type is introduced.
PASSED: Continuous integration, rev:2361 jenkins. qa.ubuntu. com/job/ mir-ci/ 3130/ jenkins. qa.ubuntu. com/job/ mir-android- vivid-i386- build/1511 jenkins. qa.ubuntu. com/job/ mir-clang- vivid-amd64- build/1510 jenkins. qa.ubuntu. com/job/ mir-mediumtests -vivid- touch/1465 jenkins. qa.ubuntu. com/job/ mir-vivid- amd64-ci/ 1127 jenkins. qa.ubuntu. com/job/ mir-vivid- amd64-ci/ 1127/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ mir-mediumtests -builder- vivid-armhf/ 1465 jenkins. qa.ubuntu. com/job/ mir-mediumtests -builder- vivid-armhf/ 1465/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ mir-mediumtests -runner- mako/4485 s-jenkins. ubuntu- ci:8080/ job/touch- flash-device/ 18561
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/mir- ci/3130/ rebuild
http://