daniel miller kirjoitti: > 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 >
some copy-paste from irc, as notes for the doc that have been working on, are in http://www.playsign.fi/engine/rex/viewerarchs/index_html#notes .. dunno if manage to make something more sensible out of that still before the end of the year but will work on some of these issues at least. hm this now seems to be going to both the general and the arch list, dunno what would be good. > the C++ port of libomv will be dealing with that issue. > good point. > 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. > +1 I also like techniques where code if not tied to a certain specific way of execution. Haven't look specifically for this yet now, but recall from somewhere that there are systems where you can run same components either in a single thread or in multiple -- where that decision has been kind of pushed up to a configuration level. I guess Twisted reaches this in some way by having the reactors in control, and also mentioned Kamaelia to Ryan earlier and he looked into it (I haven't used it earlier nor studied yet now). Also in the Intel design / Smoke demo the different subsystems just define tasks that the scheduler executes, using 1 / thread per processor (but if you have e.g. 4 you can get tasks from a single subsystem running in parallel, I don't actually know yet how they deal with concurrency there as otherwise the division to subsystems and them keeping private copies of data is how they approach parallelism). Anyhow, even simple things help, like not just having a start() call that creates a thread and runs in a while loop inside as the only way to use a library, but having also calls like poll() in network / ui / event libs and renderOneFrame() in Ogre (openviewer uses that). > 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 I've found that select() does a good job there so that threads are not always needed for I/O :) .. but yes there are places where things block, like opening a new tcp connection IIRC. > 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 > Right. There are cases where this memory sharing for true parallel execution is necessary, like in image rendering (e.g. in Blender) it makes sense to have a thread / processor and them all having access to the same scene data. The geometry for a movie scene is huge, you don't want to duplicate that. Also the usage is simple as all threads just read the memory and don't modify anything in the scene - just output pixels, which is easy to manage 'cause every worker has an own tile so nothing is shared where writing is being done. But this is exceptional, and I think for a good reason the only place in Blender where threading is used (they are right now porting stuff over for the new 2.5 architecture which has a new event system, also new windowing lib etc. basics). > 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. > Interesting. I've avoided unnecessary threading for the 1st class of reasons you mentioned, loosing determinism and needing to worry about data access, and have just heard that it is inefficient too (which of course makes sense 'cause there is additional context switching and other overhead) - never considered the execution in such detail. > 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 > The Intel design is exactly about notifications, subsystems subscribing to the type of changes in the data that they are interested in, but I don't know how the execution in that system goes w.r.t context switches .. there are no sockets but just function calls. Oh and again 1 thread / processor so I guess no context switches then .. and the tasks must be written in a non-blocking manner. > 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. > Certainly relevant for something as central as the networking component, and hopefully the LibOMV effort can take this into consideration. Otherwise I think for libraries and components to be plugged into the system, we have to be liberal in the sense that allow basically anything. If someone has a networking implementation, GUI library, a custom controller device or an AI library that uses threading heavily, I think we should have an architecture that allows them to be used. But for the core itself and for the main components that are part of the system itself we should strive for the best technique indeed. > -danx0r > ~Toni > On Wed, Dec 17, 2008 at 3:23 AM, Jeroen van Veen <j.veen...@gmail.com> wrote: > >> good news :D >> >> 2008/12/17 Ryan McDougall <sempu...@gmail.com> >> >>> Excellent, do you have any links? >>> >>> Cheers, >>> >>> On Wed, Dec 17, 2008 at 11:09 AM, Hurliman, John >>> <john.hurli...@intel.com> wrote: >>> >>>>> -----Original Message----- >>>>> From: realxtend@googlegroups.com [mailto:realxt...@googlegroups.com] >>>>> On Behalf Of Ryan McDougall >>>>> Sent: Tuesday, December 16, 2008 5:54 AM >>>>> To: realxtend@googlegroups.com >>>>> Subject: [REX] Re: new bsd-viewer >>>>> >>>>> >>>>> On Tue, Dec 16, 2008 at 3:48 PM, Jeroen van Veen <j.veen...@gmail.com> >>>>> 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/ -~----------~----~----~----~------~----~------~--~---
