On Tuesday 17 February 2015 23:40:43 Felix Freimann wrote: > Potentially, it is possible that code outside of the OIC library also > contains some form of lock for whatever reason. This means there could be a > lock inside of the OIC library and one outside (over which OIC has no > control). Hence, it is easily possible that depending on call sequence > these two locks are grabbed in a different sequence which would lead to > task lock-up's.
That is a very good point in favour of not having implicit locks inside our API and instead opt for lock-free thread-safe code. However, it's also possible to avoid this deadlock situation by never ever calling out to user callbacks with a lock held. That way, we make it impossible possible for one thread to hold an internal lock while trying to acquire an external. Or, in other words, the internal lock is always locked later, so we retain locking order. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
