Re: guile fibers - looking for adivce

[Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>]

Hi Jan!

On 9/6/20 2:47 AM, Jan Wielkiewicz wrote:
> Hello,
>
> I'm still on my way of integrating Guile Fibers and GOOPS, but I
> encountered some weird behavior.
> Say I have an object with with one slot being a vector and two methods
> accessing the vector concurrently/parallelly. The methods
> accessing/editing the vector are time consuming and are meant to be ran
> frequently. Assuming I would like to run the methods on separate
> fibers, how do I make sure the state of the object doesn't
> suddenly change during execution of a method? I would like the methods
> to be able to edit the state of the object, but in a cooperative manner.
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.
> The weird behavior I've encountered is that sometimes when running the
> first method (A) and right after starting the second method (B), the
> method B tries to access the vector before the method A finishes its
> job. What should I do to make accessing the vector cooperatively, yet
> to run the time consuming on separate fibers for concurrency?
>
> I was thinking about implementing slots in objects as sending and
> receiving messages instead of regular variables, but still there were
> some problems with the object state.
>
> Could someone explain me what should I do?

Is there a way you could avoid sharing the object? Perhaps copying it
for each fiber?

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:

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