Re: [REX] Re: new bsd-viewer

[daniel miller]

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 <j.ve...@gmail.com> wrote:
> good news :D
>
> 2008/12/17 Ryan McDougall <semp...@gmail.com>
>>
>> Excellent, do you have any links?
>>
>> Cheers,
>>
>> On Wed, Dec 17, 2008 at 11:09 AM, Hurliman, John
>> <john.h...@intel.com> wrote:
>> >
>> >> -----Original Message-----
>> >> From: real...@googlegroups.com [mailto:real...@googlegroups.com]
>> >> On Behalf Of Ryan McDougall
>> >> Sent: Tuesday, December 16, 2008 5:54 AM
>> >> To: real...@googlegroups.com
>> >> Subject: [REX] Re: new bsd-viewer
>> >>
>> >>
>> >> On Tue, Dec 16, 2008 at 3:48 PM, Jeroen van Veen <j.ve...@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
>> >
>> > >
>> >
>>
>>
>
>
> >
>

[Toni Alatalo]

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