Re: guile fibers - looking for adivce

[Jan Wielkiewicz <tona_kosmicznego_smiecia@interia.pl>]

Hi!

Dnia 2020-09-06, o godz. 02:42:20
Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> 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