On Tue, 2015-04-07 at 15:51 -0700, Thiago Macieira wrote: > On Tuesday 07 April 2015 15:14:13 Keane, Erich wrote: > > Another thought-- > > Could we perhaps expose these operations in a way that the implementer > > can specify? Basically, have a configuration step pre-Init that would > > allow the user of our stack to specify their own mutex/threading library > > instead? > > Are you talking about a step during IoTivity's configuration? Or at the load > time of the application? > > If you meant the latter, I recommend against that.
The first one. Either as a parameter to, or an optional call before the OCInit call. > > This is exactly what libdbus-1 did up until 1.2 or so: you had to initialise > the threading support by setting a bunch of callback functions so that > DBusMutex and DBusWaitCondition would work. > > That was a disaster, for two reasons: > * applications either forgot to do it or did it incorrectly, resulting in all > manners of funny (not!) thread-safety issues > > * if you loaded two libraries using libdbus-1 and they happened to call the > setup function twice, then libdbus-1 would switch from one backend to > another, > resulting in another set of funny issues -- which you'd usually only catch > when running in the user's system, when a Qt application loaded the Gtk style > plugin, which loaded caused GConf to try and connect to D-Bus... > > And the whole reason D-Bus tried to do it was so that libdbus-1 would not > depend on libpthread. We don't need that. > > > This would likely also make the need for _singlethread versions of > > things unnecessary, since the OSAL stuff could be handled by the > > implementer (plus a solid default implementation). > > > > The nice part of this is we could potentially introduce atomics in c > > ++11/C11 code, or on platforms where this would be beneficial. > > Additionally allowing the C++ stack to use std::thread (or boost > > thread!) would potentially be a popular function. > > I'm not against either, but that raises the bar of compiler support > requirement again. > > Remember we're debating whether C99 is acceptable. C11 is not a discussion... > I'm saying if we exposed a configurable thread/mutex setup that the user could use these if they cared to, not necessarily a requirement. SO, if our implementer was using GCC 5.0, they could speed their app up by specifying atomics, rather than having to use standard mutexes for single-variable locks. Alternatively, they could use OS primatives to do such speed up if requested.
