PengZheng opened a new pull request #376: URL: https://github.com/apache/celix/pull/376
Currently calling 'celix_bundleContext_useServiceWithOptions' with non-zero timeout for a non-existent service will prevent the the Celix event loop from registering any new service. Thus 'celix_bundleContext_useServiceWithOptions' blocks in vain. This PR fixed this and removed the unnecessary mutex from 'celix_bundle_context_use_service_data_t'. By removing the mutex, there is no need to destroy the mutex anymore. Why the mentioned mutex is unnecessary? In the language of C/C++11 memory model, `celixThreadMutex_unlock(&fw->dispatcher.mutex)` in `fw_removeTopEventFromQueue` **synchronizes with** `celixThreadMutex_lock(&fw->dispatcher.mutex)` in `celix_framework_waitForGenericEvent` and the implicit lock when `celixThreadCondition_timedwaitRelative` returns. Note also that `fw_handleEventRequest` **happens before** `fw_removeTopEventFromQueue` in the event loop thread and that `celix_framework_waitForGenericEvent` **happens before** what follows in the calling thread. By the above three, we can safely conclude that `fw_handleEventRequest` happens before what follows `celix_framework_waitForGenericEvent` in the calling thread. See [C++ Concurrency in Action, Second Edition, Chapter 5](https://learning.oreilly.com/library/view/c-concurrency-in/9781617294693/kindle_split_015.html#ch05lev1sec3). Please correct me if I'm wrong. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@celix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
