Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


#15 Extend the Task type


it would be useful if there could be added some more
abstract wrappers for the task type, i.e. something
that would directly allow programmers to define
dataflow relationships between different types of
tasks,that way creating multithreaded applications
using poco should become even more intuitive


  • Logged In: YES
    Originator: NO

    Sounds like an interesting idea for a future release. Want to be a bit more specific? How should the relationships be expressed in code?

  • Logged In: NO

    well, the underlying ideas was that because programming is all about identifying and implementing relationships in code -which applies in particular to parallel/threaded programming- the design and development process of parallel applications could probably be simplified by providing a certain set of task "primitives" that are specifically designed for certain usage scenarios.

    So, it's really more about enabling the framework to make certain assumptions about individual tasks:

    In general, we want our parallel components ("tasks") to be maximally concurrent, that is with as few shared state/communications as possible.
    That is, as programmers we are always looking for the "ideal task": a task that -PREFERABLY- doesn't have any external dependencies (i.e. on data or other tasks) and can be spawned multiple times concurrently.

    However, in real life we usually don't encounter such cases very often, nonetheless we have got to work with the same thread or task primitive regardless of the fact that individual tasks may very well have different requirements and scopes.

    While this wouldn't really automatically express dataflow relationship between different tasks directly in code, it could easily formalize the development process, simply by offering the programmer a well-defined set of generic task "templates", meant to be used for specific purposes.

    For example, the nature of a task may be influenced by factors such as:

    - is it designed to be a long/permanently -running task or possibly just a "fire & forget" task?
    - does it have to communicate with other tasks? does it possibly only have to communicate with parent/sub tasks of itself?
    - may the task itself be spawned multiple times or may it only run once (i.e. sort of singleton-like)?
    - does the task return any state/data to other tasks?

    data access:
    - does the task require access to data from other tasks? (which may possibly be running at the same time)?
    - does the task require 1:1 (shared) data access, or would it be sufficient to have the task work on copies of data (i.e. no locking/syncing required)?
    - what's the nature of said access: read/write?

    All of these are factors that more or less seriously affect the dataflow between different tasks in the same app.

    So, the idea would be to provide a library of task primitives with well-defined properties, that are known to work for specific scenarios-the programmer would then merely have to identify the major task components in his design and determine the required properties to decide for a specific "primitive" to use, whereas the overall objective should always be to have as few shared state/dependencies as possible per task.

  • Logged In: NO

    running mode:

    likewise, specific groups of tasks may by design have the requirement to MUST RUN either sequentially or concurrently.
    Furthermore, there may be relationships for individual tasks such as "must not be run concurrently/sequentially"

    Such a relationship, if expressed in code, would again enable the library framework to make (important) assumptions about the dataflow and synchronization requirements of this group of tasks.

  • Logged In: NO

    I think this is basically asking for something related to Ada tasks, which feature low level primitives which are then implicitly handled by a scheduler based on a set of relatively rigid requirements and assumptions that can be made for each individual task.

  • Logged In: NO

    You may want to look into QT: its high level threading support is increasingly powerful and provides for pretty advanced high level tasking constructs. And indeed, the folks at Trolltech keep on improving this stuff, there are very promising plans for upcoming versions of QT!

  • Logged In: NO

    having tasks similar to Ada in C++ would require some sort of implicit scheduler that handles synchronization, to ensure that certain threads aren't running concurrently, and that certain resources aren't accessed at the same time.