Model View Controller?

[Radium]

I have the following problem:

I have written a class which works on image data.
To be precise.... the class applies smoothening on the image with filters.

I want to visualize this proccess.
To do this i am going to write a second class, which is responsible
for displaying the smoothening in progress.

Because i only want this visualisation for control purpose, i dont want
any visualisation methods in the first class. This would deminish it's
efficency. The Model View Controller Pattern, relies heavily on
Messaging between the classes, so the first class would have
to inform the second, and as i said, i dont want any inform methods in
the first class.

My Idea is to create two threads, the first filtering the images, the second
accessing the resources(image) of the first class and displaying them from
time to time.

Any better suggestion?

THX

[Victor Bazarov]

Radium wrote:

I have the following problem:

I have written a class which works on image data.
To be precise.... [...]

My Idea is to create two threads, [..]

Any better suggestion?

Arguable but possibly better to post to 'comp.object', since C++ does
not have any built-in threading support, nor your problem is of the
language kind. Also consider 'comp.software.patterns'.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Phlip]

Radium wrote:

I have written a class which works on image data.
To be precise.... the class applies smoothening on the image with filters.

I want to visualize this proccess.
To do this i am going to write a second class, which is responsible
for displaying the smoothening in progress.

Because i only want this visualisation for control purpose, i dont want
any visualisation methods in the first class. This would deminish it's
efficency. The Model View Controller Pattern, relies heavily on
Messaging between the classes, so the first class would have
to inform the second, and as i said, i dont want any inform methods in
the first class.
The simplest form of MVC is just method calls. No threads, or Observer
Pattern.
My Idea is to create two threads, the first filtering the images, the
second
accessing the resources(image) of the first class and displaying them from
time to time.

Any better suggestion?

Ideally, the filter program's work loop should be interruptible, so an outer
loop could call it over and over again, incrementing an index which is a
member variable, each time.

Then your GUI layer could use a window timer set to 0 duration. Each timer
event calls a handler that calls the filter program a number of times -
maybe until 100 milliseconds elapse - and then collects data and triggers a
paint event. The next window handler won't run until the paint is done.

Whenever a program might use threads, I personally work hard to avoid them,
and this tends to improve the code in ways that make threads easier to
install after you need them. For example, a work loop inside another thread
could intermittently call PostMessage() (on Win32) to send a WM_USER message
to a window, and that would paint.

Such a system would use threads in almost the same configuration as my
thread-free version.

I X-posted to news:comp.object for advice from beyond C++.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Dmitry A. Kazakov]

On Wed, 05 Apr 2006 22:10:57 GMT, Phlip wrote:

Ideally, the filter program's work loop should be interruptible, so an outer
loop could call it over and over again, incrementing an index which is a
member variable, each time.
This would be a very fragile design, though. Then, if there are some time
constraints, it becomes quite difficult to handle them. Yes, it is simpler
as long as the system is small, but its complexity grows much faster than
one of natively-concurrent design.
Then your GUI layer could use a window timer set to 0 duration. Each timer
event calls a handler that calls the filter program a number of times -
maybe until 100 milliseconds elapse - and then collects data and triggers a
paint event. The next window handler won't run until the paint is done.
I would prefer a threaded design to timers. The reason is that this
provides a good isolation of things which have to be decoupled: like worker
vs. GUI, and also because it allows finer time granularity. Usually I am
using three threads:

1. Worker
2. GUI messages loop (to handle user input)
3. GUI visualization

I don't recommend to use WM_TIMER in order to merge 2 and 3. In my
experience it is cleaner to run 3 periodically, usually at 20-50ms rate for
highly dynamic data. Especially when the requirement is that 2 should never
be blocked. The design of many windows applications suffers this problem.
Another argument, is that it is a good soft-real time approach. Usually 3
would take much resources. Running it at known rate warranties that
whatever happens it wouldn't take more than that. If system gets busy one
could no the fly brake 3 by decreasing its rate. This is how oscilloscopes
and other things alike are implemented in our commercial HMI.
Whenever a program might use threads, I personally work hard to avoid them,
and this tends to improve the code in ways that make threads easier to
install after you need them. For example, a work loop inside another thread
could intermittently call PostMessage() (on Win32) to send a WM_USER message
to a window, and that would paint.

Yes, it is possible, but it is fragile and also has a poor performance.
Sending messages involves queuing (=unpredictable time) + context switches
(=wasting resources.) Protected objects (implemented on the basis of
critical sections) are much more faster and for all cleaner.

Having said that, I'd like to note that I agree with the advice to develop
components in a thread-free way. I.e. that each object is basically
passive, but is activated from outside by some pace-maker thread. The
difficult decision is though, whether a particular object need to be
thread-safe.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[H. S. Lahman]

Responding to Kazakov...

Ideally, the filter program's work loop should be interruptible, so an outer
loop could call it over and over again, incrementing an index which is a
member variable, each time.

This would be a very fragile design, though. Then, if there are some time
constraints, it becomes quite difficult to handle them. Yes, it is simpler
as long as the system is small, but its complexity grows much faster than
one of natively-concurrent design.

Right. But I think that is inherent in using MVC in the first place.
MVC presupposes a layered model structure where the dominant activity is
converting back and forth between the RDB and UI paradigms. IOW,
CRUD/USER processing. In such a context fragility is not a concern
because the view conversions are so rigorously defined. But as soon as
one starts getting into other operational concerns, like R-T
constraints, one is in a different ball game where there is no inherent
structure to prevent foot-shooting. So one needs an entirely different
model tailored to the context (in this case, asynchronous processing),
such as you suggest.

Whenever a program might use threads, I personally work hard to avoid them,
and this tends to improve the code in ways that make threads easier to
install after you need them. For example, a work loop inside another thread
could intermittently call PostMessage() (on Win32) to send a WM_USER message
to a window, and that would paint.

Yes, it is possible, but it is fragile and also has a poor performance.
Sending messages involves queuing (=unpredictable time) + context switches
(=wasting resources.) Protected objects (implemented on the basis of
critical sections) are much more faster and for all cleaner.

Having said that, I'd like to note that I agree with the advice to develop
components in a thread-free way. I.e. that each object is basically
passive, but is activated from outside by some pace-maker thread. The
difficult decision is though, whether a particular object need to be
thread-safe.

Ironically, one problem with threads is that they usually have poor
performance. Typically one is actually using the OS thread
infrastructure, which has to deal with time slicing at the instruction
level. That entails a whole lot of overhead for context switches. So I
agree with you and Phlip that one wants to look for an alternative
whenever possible.

In fact, most applications' time constraints aren't so stringent that
one needs slicing at the instruction level. So one can use slicing at
the method level where one gets context switches for free. One way to
do that is through interacting object state machines where there are
multiple event queue managers that effectively act as threads (i.e.,
only one queue pops at a time and semaphores or whatever determine who
pops next).

It is no panacea (e.g., an entire object state machine must be assigned
to a single event queue), but this sort of Poor Man's Threading is
surprisingly useful in well-formed OO applications where objects are
cohesive, responsibilities are logically indivisible, and collaborations
are peer-to-peer. It is also pretty robust because the original
asynchronous communication solution one needed for the state machine
interactions goes a long way to ensure proper sequencing and the few
situations where the developer needs to intervene explicitly are usually
pretty obvious.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hs*@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH

[Dmitry A. Kazakov]

On Thu, 06 Apr 2006 15:41:55 GMT, H. S. Lahman wrote:

Responding to Kazakov...

In fact, most applications' time constraints aren't so stringent that
one needs slicing at the instruction level. So one can use slicing at
the method level where one gets context switches for free. One way to
do that is through interacting object state machines where there are
multiple event queue managers that effectively act as threads (i.e.,
only one queue pops at a time and semaphores or whatever determine who
pops next).

Yep. Interestingly, but what you describe is actually how protected objects
work. On a single processor machine the implementation of would most likely
be one mutex for all objects. Each time a protected action ends (=the state
machine performs a transition) the barriers of the protected object entries
are reevaluated letting some threads to continue. The advantage of this
model is that if the current thread can continue, it will. This minimizes
context switches. The mutex is only used to protect the actions = state
machine transitions. The rest happens fully concurrently. So the barriers
play the role of semaphores. It is a very lightweight model. When
implemented by the language within one OS thread it should beat all other
mechanisms. Unfortunately one cannot use this at full, because when some
synchronous I/O or GUI API of the OS used they, of course, would block
everything in that is single thread. So except for rare stand-alone cases,
one should still use these clumsy OS threads. Still protected objects are
more efficient than mutexes, very OO-ish and well fit for OO decomposition.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[H. S. Lahman]

Responding to Kazakov...

In fact, most applications' time constraints aren't so stringent that
one needs slicing at the instruction level. So one can use slicing at
the method level where one gets context switches for free. One way to
do that is through interacting object state machines where there are
multiple event queue managers that effectively act as threads (i.e.,
only one queue pops at a time and semaphores or whatever determine who
pops next).

Yep. Interestingly, but what you describe is actually how protected objects
work.

I know. B-) It is one of the reasons translation insists on describing
all object behavior with object state machines. Once one has that
infrastructure and rigor, the code generator can automatically identify
objects that need to be protected based on synchronous knowledge access
and then provide the appropriate blocking management. [Alas, the
current state of the art still requires the developer to provide some
help indirectly through an MDA marking model. But the grunt work can be
automated.]
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hs*@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH