> -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > bounces at lists.iotivity.org] On Behalf Of Thiago Macieira > Sent: Wednesday, February 18, 2015 2:11 AM > To: iotivity-dev at lists.iotivity.org > Subject: Re: [dev] Ripping out the threads > > 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.
Ok, we all agree that threaded, re-entrant code is good. Deadlocks are bad. Clear locking order is good.... Can we get to some code? Can you provide concrete examples of these issues and a suggestion for something better. Let's get our hands dirty. Pat Lankswert -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7198 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150218/e8ffc07a/attachment.p7s>
