and here's the missing post: ----------------------------- one thing to keep in mind -- an issue with libomv is it runs on its own thread. Since we're thinking about issues of concurrence, parallelism, performance etc (we've been talking on IRC about that, should move to rex-arch at some point) -- I'd like to understand how the C++ port of libomv will be dealing with that issue.
My preference (and this may be true of C# libomv, I profess I haven't looked closely) would be to have an API and documentation that makes it very explicit what is going on -- ie, who is starting a thread, and what sorts of operations will be happening on that thread. It would also be nice if there were an easy way to fine-tune the thread creation process from the application layer. Using a thread to watch an I/O stream and notify other parts of the application when something occurs is, IMSHO, about the only use of threads that I have found to be useful and manageable. It sort of takes the place of interrupt-driven I/O (I may be aging myself here) -- it's morally equivalent to something I used to do in my assembly days: a high priority interrupt would do time-critical things first, then downgrade itself to a lower priority, and do less time-dependent housekeeping stuff. In effect, what an I/O driven thread is doing is something similar. The heavier use of threads popular today in languages like Java and C# (and to some extent in C++) is something entirely different. It's basically multitasking with shared memory. That leads to all the craziness with locks and sempaphores, and all the tangential issues of managing multiple asynchronous write access to a shared resource. In effect, you have to build a memory-based database layer, because you have the classic DB problems of atomicity, consistency, isolation and so on, due to the fact that you have given up determinism of the sequence of operations in your code. I'm not sure you gain enough to pay for the extra development hassle and problems debugging this style of code. Another issue I have with both threads and generalized multiprocessing (whether actual multicore or emulated) is that for a real-time system, you are very dependent on the operating system's process/thread implementation to maintain the responsiveness of the system. The maximum time the OS may take to come back to an interrupted process (on typical unix & windows machines) can vary from 1 to hundreds of milliseconds. I'm not just talking about occasional interrupts that cause a quick glitch in user-perceived responsiveness; this behavior can be constant, depending on the OS version, CPU load, etc. The upshot is that if you have two threads sharing a piece of memory as a way of communicating, the latency between one thread writing the data and the other thread reading the new value can be up to 100 ms, meaning the total back-and-forth message rate between the two threads is as low as 5 HZ. Contrast that to the paradigm of processes (or threads for that matter) communicating over sockets or pipes. What makes this method attractive is that when process A sends a message to process B, it is in effect notifying the OS that process B should wake up and do something. In most cases, this means that a context switch will happen very soon, and there is a good chance that the next process to be run will be process B, the one you just sent a message to. This post went a bit beyond the subject at hand, but these are issues that should be addressed with respect to every 3rd party library we will be utilizing for this new project. I'll cross-post this at rex-arch. -danx0r On Wed, Dec 17, 2008 at 3:23 AM, Jeroen van Veen <[email protected]> wrote: > good news :D > > 2008/12/17 Ryan McDougall <[email protected]> >> >> Excellent, do you have any links? >> >> Cheers, >> >> On Wed, Dec 17, 2008 at 11:09 AM, Hurliman, John >> <[email protected]> wrote: >> > >> >> -----Original Message----- >> >> From: [email protected] [mailto:[email protected]] >> >> On Behalf Of Ryan McDougall >> >> Sent: Tuesday, December 16, 2008 5:54 AM >> >> To: [email protected] >> >> Subject: [REX] Re: new bsd-viewer >> >> >> >> >> >> On Tue, Dec 16, 2008 at 3:48 PM, Jeroen van Veen <[email protected]> >> >> wrote: >> >>> Hi, >> >>> >> >>> Could you give some more details about the newly planned viewer? >> >>> What i would like to know is: >> >>> * Will the new viewer be based on libomv? >> >>> if not: are there plans for a c++ libomv port? >> >>> if so: then the new viewer will be written in c#? >> >>> >> >>> thanks, >> >>> >> >>> Jeroen van Veen >> >> >> >> It is expected that the new viewer will be written in C++ with some >> >> python where appropriate. It was decided not to complicate the matter >> >> with 3 languages, so no libomv has been decided against. >> >> >> >> We have two alternatives, an existing library in C called >> >> funsl/funomv, and writing our own minimal C++ version. >> >> >> >> >> >> Cheers, >> >> >> > >> > We (libomv) also apparently have a C++ port of libomv that should be >> > released "real soon now". I'm not sure how polished it is but it could be a >> > starting point. >> > >> > John >> > >> > > >> > >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ this list: http://groups.google.com/group/realxtend realXtend home page: http://www.realxtend.org/ -~----------~----~----~----~------~----~------~--~---
