Model View Controller?

Discussion in 'C++' started by Radium, Apr 5, 2006.

  1. Radium

    Radium Guest

    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?

    Radium, Apr 5, 2006
    1. Advertisements

  2. 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 ''.

    Victor Bazarov, Apr 5, 2006
    1. Advertisements

  3. Radium

    Phlip Guest

    The simplest form of MVC is just method calls. No threads, or Observer
    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 for advice from beyond C++.
    Phlip, Apr 5, 2006
  4. 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.
    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.
    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
    Dmitry A. Kazakov, Apr 6, 2006
  5. Radium

    H. S. Lahman Guest

    Responding to Kazakov...
    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.
    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

    Pathfinder Solutions -- Put MDA to Work
    H. S. Lahman, Apr 6, 2006
  6. 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.
    Dmitry A. Kazakov, Apr 6, 2006
  7. Radium

    H. S. Lahman Guest

    Responding to Kazakov...
    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

    There is nothing wrong with me that could
    not be cured by a capful of Drano.

    H. S. Lahman

    Pathfinder Solutions -- Put MDA to Work
    H. S. Lahman, Apr 8, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.