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
