Using ModelDriven for parallel computing

CapableObjects Forums SupportForum Using ModelDriven for parallel computing

This topic contains 2 replies, has 2 voices, and was last updated by  efim 2 weeks, 6 days ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #5007 Score: 0

    efim
    Participant

    Hi,

    I would like to parallelize a method running currently in one EcoSpace.

    One option would be instantiating several EcoSpaces and run the parts parallel. However I would run into the problem of data integrity when saving results in DB because the DB transactions are not supported by ECO

    Another option is to run all parts in one EcoSpace, but what is with Multithreading? After some tests I observed that at least the UndoService causes problems for my algorithm. Perhaps there are other problems but can I at least deactivet UndoService in EcoSpace?

    thanking in advance for your tips
    /Efim

    #5008 Score: 0

    Admin
    Keymaster

    Multithreading is straight forward as long as you divide and isolate data usage to unique threads – and avoid working on the same stuff from different threads.

    As long as you do not respect the data isolation idea you have a rather nasty problem on your hands no matter what framework you use.

    The biggest isolation is to create separate ecospaces as you say.
    But you do not have to be that drastic.

    You can work with ABC on one thread and DEF on another – but you cannot easily handle things as lazy fetch, in memory transactions and undo/redo since the dataset ABC will use the same services as DEF – and then you have not isolated the data usage to unique threads.

    Whatever your needs are I would say you will always need to think like this:
    1. In one coordinating thread do some linear planning of dividing the work into isolated buckets that do not share state (that can change) in any way
    2. Spin up threads to work in parallel on each bucket from 1.
    3. In the coordinating thread – wait for the parallel work to finish – then – if needed – do some linear work of harvesting the result.

    #5010 Score: 0

    efim
    Participant

    > You can work with ABC on one thread and DEF on another – but you cannot easily handle things as lazy fetch, in memory transactions and undo/redo since the dataset ABC will use the same services as DEF – and then you have not isolated the data usage to unique threads.

    That”s exactly my point.
    avoiding Lazy fetch -> all instances are preloaded: OK
    avoiding in memory transactions -> I don”t use it at this place: OK
    avoiding undo/redo -> each EcoSpace state change invokes Undo implicitly with a shared Undo-list. The best way I think would be deactivating it at all. But is it possible? Or separation of Undo-lists – one per thread – would be the only solution?

    /Efim

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.

Comments are closed.