Hi! Dnia 2020-09-06, o godz. 02:42:20 Zelphir Kaltstahl <[email protected]> napisał(a):
> Hi Jan! > > Call me uneducated, but I believe, if you are accessing shared memory, > in this case the shared member vector of the object, you will have to > resort to things like locking mechanisms. I don't know of any other > way, except for not using shared memory and keeping one copy per > fiber or per concurrently running execution unit. I'll probably go with some locking mechanism then. > Is there a way you could avoid sharing the object? Perhaps copying it > for each fiber? Fortunately, at least for now, one procedure updates the array and the other only reads it. We'll see how scalable is my idea when the project grows. > If not, then perhaps there is yet another way. A while ago I read some > article, which had the heading "pull not push" or something. So > instead of having multiple concurrent execution units trying to > update the vector, perhaps you could have multiple concurrent > execution units, which are each responsible for some exclusive part > of the state of a data structure and working on their own parts of > the memory of it and update it by retrieving information from the > system. Perhaps this is clearer, if I link to the article I read: Sounds interesting, thanks. Maybe I'll find use for this later. > https://nullprogram.com/blog/2020/04/30/ > > This might only work in cases, where the data lends itself to such > "other way around" of updating state. > > > Thanks in advance > > Jan Wielkiewicz > > Out of ideas for now. > > Regards, > Zelphir > > Anyway, thanks for ideas. Jan Wielkiewicz
