[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guile fibers - looking for adivce
From: |
Jan Wielkiewicz |
Subject: |
Re: guile fibers - looking for adivce |
Date: |
Mon, 7 Sep 2020 18:34:40 +0200 |
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
Re: guile fibers - looking for adivce, Chris Vine, 2020/09/06