That said, given the thread-safe layers above and below the C stack (the C++ layer and the new CA layer, respectively), it would be nice to make the C stack thread-safe.
-----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Hudson, Douglas Sent: Tuesday, February 17, 2015 3:54 PM To: Macieira, Thiago; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Ripping out the threads A little bit of history regarding the C stack. It was implemented first and wasn't originally intended to be thread-safe. The initial thought was that that would allow it to run efficiently and have less of a footprint on a bare-metal micro with no RTOS (i.e. single threaded). If an app wanted to use threads, then the app should provide a mutex based on its OS/RTOS and serialize access to the C stack. The C++ layer did this for devices that weren't resource constrained. Early implementation goals for the C stack were: - to be as small as possible so that we could run on a wide variety of constrained devices - RTOS/OS agnostic -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: Tuesday, February 17, 2015 3:27 PM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Ripping out the threads On Tuesday 17 February 2015 11:35:33 Keane, Erich wrote: > > > Removing the threads spawned upon message retrieval wouldn't be > > > that big of a deal, however it would cause a few problems. Note > > > that each of these is called in the C-context, so it would result > > > in user-code freezing the message pump and likely introducing a > > > number of delays in message receiving. > > > > > > Right, but that's exactly what we're asking for in the C library > > anyway, so what's the harm? If threads are necessary to do the work > > of a request, then the user should spawn a thread to do said work, > > as opposed to forcing a thread on the user. It's possible that the > > user's application is not thread-safe, so they have no option but to > > run everything in the same thread. > > > > I could go either way on it then I guess. I liked the idea that the > C++ stack was less error prone and was closer to 'just works' and hid > a lot of the C 'gotchas' that we have. I'm not disputing the making of an easier API. I'm all for that. But I do question using that as an excuse for having a bad API in C. If we're going to have a C API at all, it should be good enough to stand on its own. And that's why I am asking to make it thread-safe or, at the very least, reentrant if the functions are called with different objects. > > > I am curious in what way you find the C++ implementation to not be > > > thread safe? It should be safe to call the C++ implementation > > > from a number of threads, and we have an example that does just that. > > > > > > Any part of it? Including OCProcess, OCPlatform, etc? I simply can't > > see how the C++ layer can be thread-safe if the C layer isn't. Unless > > you're about to tell me that the C++ layer doesn't use the C layer > > at all... > > > The C++ layer controls access to the C layer with mutexes, essentially > forcing access to the C layer to be serialized. It doesn't solve > re-entrance problems, but it should be thread safe at least (though > not entirely taking advantage of the threading). Which reentrancy problems are you thinking of? Let's make sure we're talking about the same thing when we say "reentrant". The common definition of it is that the function can be re-entered simultaneously from multiple threads as well as re-entered from the same thread, so long as the objects passed in parameters are different. That usually has two consequences: 1) if two threads independently call the same function on different objects, they should work and not interfere with each other. Any shared global state needs to be protected by a mutex. 2) if the same thread calls back into a function that is already running, the function behave as expected (e.g., not deadlock). That's usually accomplished by always dropping locks before calling out to user code. I'm mostly thinking of #1 here, but #2 also applies there's extensive use of callbacks, like we do. > > Think of an application that uses two independent libraries that > > each want to use IoTivity. The application doesn't know (and doesn't care) that > > the two libraries use our libraries. Our libraries must work for > > multiple consumers in the same process, whether they are used from > > the same thread or not. > > > The concern there is that both libraries would potentially be running > their own Process thread, which would cause a massive performance hits. > At the moment our C++ thread SHOULD work in exactly this case however. Why would there be performance problems by running multiple threads that handle sockets? If we decide to use a common thread for all users, behind the scenes, that's fine. But it should be transparent to all users. More importantly, the user should not see this thread and should never get callbacks called in this thread. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
