John, I am sure that you get this, but will say it anyway.
Before I justify threading, let me add to your argument. There has been a push in high-performance systems and server design to reduce threading and raise the load ceiling. Why? Contention performance is hard to manage and context switches are expensive. For example, just checking a mutex is expensive. If all of the threads start bottlenecking on a mutex, the cost of multi-threading goes up significantly with little benefit. Every time a thread blocks on a mutex (or IO) and triggers a context switch the scheduler is burning CPU. The cost was so high on Windows that "fibers" (a light weight user space scheduler) were introduced to reduce the OS scheduling overhead. Now the other side, the stack needs to operate in the environments that the operating systems provides. Threading/concurrency issues are unavoidable as requests to the stack come from any thread. We can (and should) marshal these is a sane way to simplify concurrency and hopefully reduce/eliminate contention. For example, It would be nice if we could use select() or epoll() to wait on all stack events (IO or mutex). Unfortunately not all operating system and IO interface support it the same way. That is, I may not be able to listen to a Bluetooth connection using select(). Pat From: Light, John J Sent: Wednesday, April 15, 2015 11:49 AM To: Lankswert, Patrick; myeong.jeong at samsung.com; iotivity-dev at lists.iotivity.org Subject: RE: [dev] glib All this talk about threads is predicated on the assumption that threads are needed at all. This assumption has bifurcated the connectivity tree, doubling ongoing maintenance and development efforts when we are already resource constrained. I dare anyone to show that a well single-threaded IoTivity application has less than 80% of the performance of a fully multi-threaded version in a real use case. (I am not assuming that the current "_singlethread" code is representative.) The IoTivity code doesn't have any of the characteristics of an application likely to benefit from threading. It's primary purpose is to connect to I/O devices that are inherently serialized, and the most CPU-intensive parts of IoTivity are PDU-coding and DTLS cryption, which I believe are unlikely to affect real world IoTivity performance. OTOH, there is value in threading. * One optional thread to run the IoTivity stack top-to-bottom, disconnecting it from the application thread. This one thread would raise my dare (above) to 95%. * One optional thread to deliver C++ callbacks, further isolating IoTivity from the application. This thread wouldn't affect performance, just robustness. These threads wouldn't be running in parallel in any IoTivity code, so general mutex locks wouldn't be needed. They would communicate entirely through shared queues (which would of course be protected. :)) In any case, the IoTivity stack would be run on a select() function call, greatly simplifying the architecture. Of course, further optional threads could be added, but we could wait until some value was demonstrated. John From: [email protected] <mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of Lankswert, Patrick Sent: Wednesday, April 15, 2015 5:40 AM To: myeong.jeong at samsung.com <mailto:myeong.jeong at samsung.com> ; iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] glib MJ, Answers are inline. From: [email protected] <mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of ??? Sent: Wednesday, April 15, 2015 7:24 AM To: iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] glib Hi, everyone. I'd like to say on the current CA aspect, CA uses 'threadpool', 'thread' and the 'mutex' of 'glib' to synchronize multi-thread for rich devices. To avoid license issue, CA and 'glib' linked dynamically. [PCL, 2015-04-15] Yes, this works for Ubuntu, but may not everywhere. I think multi-thread running model should be supported for rich devices to utilize device resources fully. The number of threads can be configurable for the device, [PCL, 2015-04-15] I cannot see how limiting the thread pool in CA would work. Since many parts of CA grab a thread and keep it, it looks like limiting the number of threads will only cause initialization failures or deadlocks (waiting for a thread in the pool to free) when the thread pool is exhausted. And lite device operated by RTOS doesn't need glib dependency, it can run with single-thread model. [PCL, 2015-04-15] Why would you want them to run single-threaded? A number of RTOS have threading. The 'glib' can be removed if we find any alternative as we already have wrapped around 'glib'. [PCL, 2015-04-15] glib is a rich and valuable body of code. glib is a great framework for general purpose linux environments and I would encourage its use over reinventing the functionality. It is not a bad choice for embedded linux environments if you can avoid the licensing issues. It is just a poor choice for platforms that do not provide it natively. 1.7-3MB is a big hit when you have to bundle it with your application in order to support three interfaces. These are considerations that need to be taken into consideration when binding to an external library. Please remember for example that many (most?) Android and iOS application that leverage native development libraries bundle all the architectures (ARM, ARMv7, x86, etc) in their download. I have not seem the ARM version of glib, but the x86 version if 1.7MB. Multiply that times three and you are requiring 5MB download for glib before you add our libraries. In general, if you want to build portable code, you need to be very careful about what you depend upon. Thanks. Best Regards, --- MyeongGi Jeong Senior Engineer, Software Architect Software R&D Center, Samsung Electronics Co., Ltd. +82-10-3328-1130 ------- Original Message ------- Sender : Light, John J<john.j.light at intel.com <mailto:john.j.light at intel.com> > Date : 2015-04-15 04:57 (GMT+09:00) Title : Re: [dev] glib Please remove it, but don't underestimate how much work it will be. The threading architecture of CA was written assuming profligate use of independent threads, so extricating IoTivity from glib's clutches will require much restructuring. John -----Original Message----- From: [email protected] <mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:iotivity-dev-bounces at lists.iotivity.org] On Behalf Of Rees, Kevron Sent: Tuesday, April 14, 2015 12:51 PM To: Lankswert, Patrick Cc: iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] glib You should be using glib for mainloop functionality as well (avoids having to use threads at all), but it should be pluggable (able to be replaced with Qt or other mainloops systems as desired). On Tue, Apr 14, 2015 at 11:45 AM, Lankswert, Patrick wrote: > To all, > > The introduction of glib has complicated the stack in a number of ways > from licensing to OS support and beyond. > > In the future, do not draw in additional libraries into Iotivity > without vetting it in this forum. > > I plan to remove the glib dependency from iotivity for several reasons: > 1) IANAL, but the license has viral requirements including the fact > that a dynamically linked LGPL library must be replaceable which is a > problem for RTOSes and linux-based devices TVs and Access Points. > 2) Glib support on iOS (not directly supported), OSX and Windows > (requires > MSYS) is problematic > 3) It is my understanding that we are only using glib for threads and mutex. > This is a lot to pull into iotivity for only two features. > > Before I make this official, I would like to understand any reason > that glib should be kept. Are we using glib for anything other than > threads and mutexes? > > Pat > > Patrick Lankswert > > Intel Corporation > Platform Engineering Group (PEG) / Communications and Devices Group > (CDG) Engineering Manager Louisville, KY, USA > > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at > lists.iotivity.org> > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org <mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150415/a2d359df/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150415/a2d359df/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 823 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150415/a2d359df/attachment.jpg> -------------- 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/20150415/a2d359df/attachment.p7s>
