From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Zelphir Kaltstahl Newsgroups: gmane.lisp.guile.user Subject: Re: guile fibers - looking for adivce Date: Sun, 6 Sep 2020 02:42:20 +0200 Message-ID: <8f3fb4a5-4bad-4ebf-77bf-78826fdbc996@posteo.de> References: <20200906024757.58dd34cd@interia.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28318"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: guile-user@gnu.org To: tona_kosmicznego_smiecia@interia.pl Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Sun Sep 06 02:42:39 2020 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kEilS-0007HS-E1 for guile-user@m.gmane-mx.org; Sun, 06 Sep 2020 02:42:38 +0200 Original-Received: from localhost ([::1]:60028 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kEilR-0003g9-GJ for guile-user@m.gmane-mx.org; Sat, 05 Sep 2020 20:42:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56212) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kEilI-0003fs-CM for guile-user@gnu.org; Sat, 05 Sep 2020 20:42:28 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:54179) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kEilF-0002Pr-He for guile-user@gnu.org; Sat, 05 Sep 2020 20:42:28 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id AF55816005C for ; Sun, 6 Sep 2020 02:42:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1599352941; bh=kZXY6pDjuoZhZQ5tlB2e3BCMG7q2WbkO23Gqx4+0QJ0=; h=To:From:Autocrypt:Subject:Cc:Date:From; b=cW0JGbxlvXV6VlsgEHVgX5YF4JAt0hZZi2e5opyEWagO2c1AFy23lWy7GGQmMsA6i oKEbHvzolR02I2S22OPKbrCDkQPNvP9g7rJ2j+1cA93Zt7KyS4tOWGrS3mBGrBE6w0 ZV0/ZCuPvdtrCKx1WypVwbKUilfX3ig8XeFPjZhDSHZScQzGBSISThmN3xmh3i/GkQ 33EI7o3RXEL9E8xxbym1fe065l6bMhEgyxKzScAnXQHWSt2RLOkUOfGx/axmEnhaYn Xp8FPKdhAZ5IwfSYCleIRYD5ygYtyCLVpBm3I+WVVma/KNE0qzEv4u7giLx2bOYg+T DTQioliDCs/Dw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4BkXgK0v8Bz9rxM; Sun, 6 Sep 2020 02:42:20 +0200 (CEST) Autocrypt: addr=hwroitzsch@posteo.net; prefer-encrypt=mutual; keydata= xsFNBF3RPUYBEADWxyXN1cuFxb1XSdrZ6lZ8VlBfD8pYY7oWAAmvjBv4GUAMwMkRYQBPIPFs sRbJC1hGH0qgDN2HhgFQaGEkd0HxLzXiMHvOb9W87i2UyKjZOi8+3weoumcYj5PL9CMj/868 kj2sR9Uu7ovGelbFHZqd4elTZu+DEA/VECsIErewMs9hPA5UuZTLCLoFZEbsXDDy9DvDMpEF jmLCg1lFgTx1Gmj/sWPMja29gvybLYdBSO0lV73aUP2S3rwRgmCpEvh8/sd5TFu1OtewsX4b 1dt9L7ku2sVsx1sh18moi+iUkz6BElno+oBgPGc8NrrDOYHK+Aw2Ko/SZhG0eFa6w/YxuJg3 INMFakvaiiftS6o/qMTTB9KZ2vei2HQ/ua/FoqD+adCYIiMCgGHtdyDOrHQLxZhupvSuAr9V vO30ZpUfx98rjGFRty7QtxCTVDRa2DuYD6vgUNb0kCwrWeQIgwXGEVCEyxYJutOEM5d7leUo MX8zMoT2o3L2E0HdfArj7OmwiYAOaEcWy/LFvOvaJ/mfF5auqqUuLByDwD2RgqMhPwalPV8D prTHfiKm5ITFUD8AYFQvGs6F9kb45ZwnLCGAI9R4eiNSQvQSdwZ6ZvZuAdTzaUa3XcDZogMb a6dhPiFfhSaHLfbtgCgFvlKkN2s0RyqZhJPR4f3UYFEj2pmE2QARAQABzSxIYW5zLVdlcm5l ciBSb2l0enNjaCA8aHdyb2l0enNjaEBwb3N0ZW8ubmV0PsLBfQQTAQgAJwUCXdE9RgIbIwUJ CWYBgAULCQgHAg In-Reply-To: <20200906024757.58dd34cd@interia.pl> Content-Language: en-US Received-SPF: pass client-ip=185.67.36.65; envelope-from=zelphirkaltstahl@posteo.de; helo=mout01.posteo.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/05 20:42:22 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.107, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.io gmane.lisp.guile.user:16865 Archived-At: 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= =2E 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