On Tuesday 07 April 2015 15:55:14 Keane, Erich wrote:
> 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.

Er... that's the second one.

For "during IoTivity's configuration", I meant as an option to Scons when 
compiling IoTivity in the first place.

Allowing it to be done at runtime is a recipe for disaster, in my experience.

> 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.

Right, that is acceptable.

Again, learnings from D-Bus: one version added support for 
dbus_threads_init_default(), which basically initialised to pthread on Unix 
systems and some Windows equivalent on Windows. The next version deprecated 
both calls and initialised threads automatically, with the deprecated 
dbus_threads_init() with the callback set becoming a no-op.

At the same time, it began using the atomic primitives from GCC. GCC as well 
as Clang and ICC have supported the __sync_xxx primitives for years, whereas 
the newer __atomic_xxx functions appeared in GCC 4.7 (usable outside of x86 on 
4.8), Clang 3.3 and ICC 13.1. See 
http://code.qt.io/cgit/qt/qtbase.git/tree/src/3rdparty/forkfd/forkfd_gcc.h 
(Intel copyright, feel free to copy to IoTivity).

Windows has equivalent functions, the InterlockedXxxx ones.

So, even though we can't depend on the C11 <stdatomic.h> header, we may be 
able to use the intrinsics that the header would have used.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

Reply via email to