From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chris Vine Newsgroups: gmane.lisp.guile.devel Subject: Re: wip-ports-refactor Date: Wed, 11 May 2016 11:42:54 +0100 Message-ID: <20160511114254.6b87c024@bother.homenet> References: <87twjempnf.fsf@pobox.com> <20160424120519.2a44127e@bother.homenet> <87h9e6q92x.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1462963397 12985 80.91.229.3 (11 May 2016 10:43:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 May 2016 10:43:17 +0000 (UTC) Cc: guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed May 11 12:43:11 2016 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b0Rbi-0000ol-PF for guile-devel@m.gmane.org; Wed, 11 May 2016 12:43:10 +0200 Original-Received: from localhost ([::1]:51560 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0Rbi-0008CV-6t for guile-devel@m.gmane.org; Wed, 11 May 2016 06:43:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0Rbb-0008Af-R4 for guile-devel@gnu.org; Wed, 11 May 2016 06:43:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b0RbX-0005BF-Ho for guile-devel@gnu.org; Wed, 11 May 2016 06:43:02 -0400 Original-Received: from smtpout4.wanadoo.co.uk ([80.12.242.68]:27654 helo=smtpout.wanadoo.co.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0RbX-0005Ad-5F for guile-devel@gnu.org; Wed, 11 May 2016 06:42:59 -0400 Original-Received: from bother.homenet ([95.146.108.51]) by mwinf5d50 with ME id syiu1s00C16aDiv03yiuVp; Wed, 11 May 2016 12:42:56 +0200 X-ME-Helo: bother.homenet X-ME-Date: Wed, 11 May 2016 12:42:56 +0200 X-ME-IP: 95.146.108.51 Original-Received: from bother.homenet (localhost [127.0.0.1]) by bother.homenet (Postfix) with ESMTP id 3D5B7121E5B; Wed, 11 May 2016 11:42:54 +0100 (BST) In-Reply-To: <87h9e6q92x.fsf@pobox.com> X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.30; i686-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.12.242.68 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:18302 Archived-At: On Tue, 10 May 2016 16:30:30 +0200 Andy Wingo wrote: > I think we have no plans for giving up pthreads. The problem is that > like you say, if there is no shared state, and your architecture has a > reasonable memory model (Intel's memory model is really great to > program), then you're fine. But if you don't have a good mental model > on what is shared state, or your architecture doesn't serialize loads > and stores... well there things are likely to break. Hi Andy, That I wasn't expecting. So you are saying that some parts of guile rely on the ordering guarantees of the x86 memory model (or something like it) with respect to atomic operations on some internal localised shared state[1]? Of course, if guile is unduly economical with its synchronisation on atomics, that doesn't stop the compiler doing some reordering for you, particularly now there is a C11 memory model. Looking at the pthread related stuff in libguile, it seems to be written by someone/people who know what they are doing. Are you referring specifically to the guile VM, and if so is guile-2.2 likely to be more problematic than guile-2.0? Chris [1] I am not talking about things like the loading of guile modules here, which involves global shared state and probably can't be done lock free (and doesn't need to be) and may require other higher level synchronisation such as mutexes.