>From what I've seen (and addressed in at least one case) the "single thread" and "multi-thread" versions of the majority of the code should be unified and the distinction dropped.
A few places warrant an "embedded" or "lite" variant, but most of those are currently split into platform specific files (e.g. files under folders named "arduino"). Also it appears the naming of *_singlethread.h/.c was a misnomer and the original architectural intent was more of "lite" platforms where "lite platforms don't support threads" was one assumption. On 04/15/2015 10:08 AM, Light, John J wrote: > Pat, > > Are you saying there is no hope of ever eliminating the bifurcation of CA > code into "single thread" and "multi-thread" versions of critical code? > That's harsh for our future. > > John > > -----Original Message----- > From: Lankswert, Patrick > Sent: Wednesday, April 15, 2015 10:03 AM > To: Keane, Erich > Cc: iotivity-dev at lists.iotivity.org; Light, John J; myeong.jeong at > samsung.com > Subject: RE: [dev] glib > > Erich, > > Of course. At least one (probably more) thread will be needed and thread > protection (mutex) will be required. > > As we look for ways to reduce threading the existing CA thread must be > supported. > > Pat > >> -----Original Message----- >> From: Keane, Erich >> Sent: Wednesday, April 15, 2015 12:55 PM >> To: Lankswert, Patrick >> Cc: iotivity-dev at lists.iotivity.org; Light, John J; myeong.jeong at >> samsung.com >> Subject: Re: [dev] glib >> >> I definitely agree that we should attempt to remove as many threads as >> possible from the csdk/connectivity stack. However, I also see that getting >> rid of threads entirely would be unlikely. >> >> Therefore, I believe that creating an OSAL thread-pool to remove the glib >> dependency has definite advantages. >> >> -Erich >> >> >> On Wed, 2015-04-15 at 16:51 +0000, Lankswert, Patrick wrote: >>> John, >>> >>> Right on. These are the types of solutions that I was thinking about >>> also. I omitted in a vain attempt to reduce the amount of time that I >>> spend typing email. J >>> >>> Pat >>> >>> >>> >>> From: Light, John J >>> Sent: Wednesday, April 15, 2015 12:48 PM >>> To: Lankswert, Patrick; myeong.jeong at samsung.com; >>> iotivity-dev at lists.iotivity.org >>> Subject: RE: [dev] glib >>> >>> >>> >>> >>> Pat, >>> >>> Thank you for expanding on the issue. I also didn?t mention the >>> ?latency vs. throughput? contention that threads contribute to. >>> >>> I?m sure you get these other issues, but I will remind you anyway. >>> >>> ?Threading/concurrency issues are unavoidable? Near the top of the >>> stack should be a queue that eliminates the concurrency for the rest >>> of the stack. The queue might feed the first optional thread I >>> mentioned (and would use it in any rich environment) to maintain >>> concurrency with the application. >>> >>> ?may not be able to listen to a Bluetooth connection using select()? >>> A well-constructed select loop can include polling (if that is >>> needed) or external events (if that is needed). I?ve done both, and >>> they work fine. >>> >>> John >>> >>> >>> >>> From: Lankswert, Patrick >>> Sent: Wednesday, April 15, 2015 9:30 AM >>> To: Light, John J; myeong.jeong at samsung.com; >>> iotivity-dev at lists.iotivity.org >>> Subject: RE: [dev] glib >>> >>> >>> >>> >>> 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. J) >>> >>> 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: 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; iotivity-dev at lists.iotivity.org >>> Subject: Re: [dev] glib >>> >>> >>> >>> >>> MJ, >>> >>> Answers are inline. >>> >>> >>> >>> From: 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 >>> 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> >>> >>> 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: 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 >>> 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 >>>> 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 >>> _______________________________________________ >>> iotivity-dev mailing list >>> iotivity-dev at lists.iotivity.org >>> https://lists.iotivity.org/mailman/listinfo/iotivity-dev >>> >>> >>> >>> >>> >>> Image removed by sender. >>> >>> >>> _______________________________________________ >>> 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 > -- Jon A. Cruz - Senior Open Source Developer Samsung Open Source Group jonc at osg.samsung.com
