[Top][All Lists]

[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


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

> 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.

> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]