April 28, 2017 at 9:54 pm #5007
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
/EfimMay 1, 2017 at 3:23 pm #5008
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.May 2, 2017 at 8:56 am #5010
> 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?
You must be logged in to reply to this topic.