[MIT-Scheme-devel] Symmetric MultiProcessing

2016-01-03 Thread Friar Puck
Bless me, Yon Schemish, for I have Schemed. It has been 14 months since my last confession and I now have a not-entirely-unstable SMP branch. Edwin seems to be working quite well, and --processors 2 continues to get it done in ~60% of the time. I have to turn the timer interrupts way up and hit E

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2016-01-03 Thread Matt Birkholz
> From: Taylor R Campbell > Date: Thu, 20 Aug 2015 16:57:25 + > > [...] > The safe way to do this is: > > (let ((p (cons item constant-space-queue))) > (membar-write) > (set! constant-space-queue p)) > > (let ((queue constant-space-queue)) > (membar-read) > (if (and (not (eq? '() qu

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-08-20 Thread Taylor R Campbell
Date: Wed, 19 Aug 2015 17:36:38 -0700 From: Matt Birkholz > From: Taylor R Campbell > Date: Tue, 18 Aug 2015 22:39:22 + > > [...] or prove that the memory barriers are not necessary for other > reasons. I thought we were all cool with assuming word-sized memory cohe

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-08-19 Thread Matt Birkholz
> From: Taylor R Campbell > Date: Tue, 18 Aug 2015 22:39:22 + > > [...] or prove that the memory barriers are not necessary for other > reasons. I thought we were all cool with assuming word-sized memory coherency. Doesn't the x86-64 architecture guarantee that a word like constant- space-qu

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-08-19 Thread Taylor R Campbell
Date: Tue, 18 Aug 2015 18:40:09 -0700 From: Matt Birkholz > From: Taylor R Campbell > Date: Tue, 18 Aug 2015 22:41:36 + > > The use of WITHOUT-INTERRUPTS in gcfinal.scm was largely for interrupt > safety, not just for exclusion between threads, so that hitting ^G at

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-08-19 Thread Taylor R Campbell
Date: Tue, 18 Aug 2015 16:35:59 -0700 From: Matt Birkholz > From: Taylor R Campbell > Date: Tue, 18 Aug 2015 22:32:20 + > > [...] unless you've changed the way keyboard interrupts work so that > they are actually delivered by thread events, that change breaks the > m

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-08-18 Thread Matt Birkholz
> From: Taylor R Campbell > Date: Tue, 18 Aug 2015 22:41:36 + > > The use of WITHOUT-INTERRUPTS in gcfinal.scm was largely for interrupt > safety, not just for exclusion between threads, so that hitting ^G at > an inopportune moment would not leak scarce resources. Please restore > that prop

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-08-18 Thread Matt Birkholz
> From: Taylor R Campbell > Date: Tue, 18 Aug 2015 22:32:20 + > > [...] unless you've changed the way keyboard interrupts work so that > they are actually delivered by thread events, that change breaks the > major reason why we care about interrupt safety in the first place. I think we're OK

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-08-18 Thread Taylor R Campbell
The use of WITHOUT-INTERRUPTS in gcfinal.scm was largely for interrupt safety, not just for exclusion between threads, so that hitting ^G at an inopportune moment would not leak scarce resources. Please restore that property of it with appropriate WITHOUT-INTERRUPTION. ___

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-08-18 Thread Taylor R Campbell
commit 4781c478630f3c19373aea69cca3d2efac8154ee Author: Matt Birkholz Date: Tue Jun 23 11:42:13 2015 -0700 But there is no need for default/gc-flip to remove items from the queue. Flush-purification-queue! will know that its queue is "empty" when its head is in constant space

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-08-18 Thread Taylor R Campbell
You seem to have replaced WITHOUT-INTERRUPTS by WITH-THREAD-EVENTS-BLOCKED (via WITHOUT-INTERRUPTION). I don't think that's correct even under the assumption that it is to be used only for interrupt safety and not exclusion of other threads. In particular, I don't think it blocks keyboard interru

[MIT-Scheme-devel] Symmetric MultiProcessing

2015-08-18 Thread Friar Puck
> From: Friar Puck > Date: Mon, 23 Feb 2015 16:01:13 -0700 > > > From: Friar Puck > > Date: Sun, 21 Dec 2014 13:03:25 -0700 > > > > [...] > > > > Encouraging results are just what SOMEONE needs when going in the ring > > with up to 104(!) possible demons in the guise of without-interrupts. > >

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-03-03 Thread Taylor R Campbell
Date: Tue, 3 Mar 2015 16:02:15 -0700 From: Friar Puck > From: Taylor R Campbell > Date: Tue, 3 Mar 2015 20:50:54 + > > HASH-TABLE/CLEAN! probably shouldn't cons. Then it shouldn't call maybe-shrink-table! and cons a shorter vector :-(but not one bucket pair). If we

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-03-03 Thread Friar Puck
> From: Taylor R Campbell > Date: Tue, 3 Mar 2015 20:50:54 + > >Date: Tue, 3 Mar 2015 13:14:47 -0700 >From: Friar Puck > >The first use of without-interruption is in hash-table/clean!. I >don't see the need. An abort during a cleaning should be harmless. >Each splice p

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-03-03 Thread Taylor R Campbell
Date: Tue, 3 Mar 2015 20:50:54 + From: Taylor R Campbell Date: Tue, 3 Mar 2015 13:14:47 -0700 From: Friar Puck I considered that, but the abstraction seemed generally useful (and widely neglected), Scheme mutexes are cheap to create, and more are better,

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-03-03 Thread Taylor R Campbell
Date: Tue, 3 Mar 2015 13:14:47 -0700 From: Friar Puck The first use of without-interruption is in hash-table/clean!. I don't see the need. An abort during a cleaning should be harmless. Each splice produces a valid bucket. Only new-size! really needs to protect against an abo

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-03-03 Thread Friar Puck
> From: Taylor R Campbell > Date: Mon, 2 Mar 2015 23:54:09 + > >Date: Mon, 2 Mar 2015 16:34:41 -0700 >From: Friar Puck > >OK. The without-interrupts in hashtb.scm are actually spelled >"with-table-locked". I replaced them with "without-interruption". >The critical sect

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-03-02 Thread Taylor R Campbell
Date: Mon, 2 Mar 2015 16:34:41 -0700 From: Friar Puck OK. The without-interrupts in hashtb.scm are actually spelled "with-table-locked". I replaced them with "without-interruption". The critical sections could probably be narrowed if aborts are now the sole concern. I'm not s

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-03-02 Thread Friar Puck
> From: Taylor R Campbell > Date: Mon, 23 Feb 2015 23:13:58 + > > [...] > > Correct. Same with, e.g., the WITHOUT-INTERRUPTS in hashtb.scm. OK. The without-interrupts in hashtb.scm are actually spelled "with-table-locked". I replaced them with "without-interruption". The critical section

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2015-02-23 Thread Taylor R Campbell
Date: Mon, 23 Feb 2015 16:01:13 -0700 From: Friar Puck The condvar.scm file already serializes its operations, yet still uses without-interrupts, presumably for another reason. I am guessing that the intention is to stave off "aborts" or ANY keyboard interrupt that could eventu

[MIT-Scheme-devel] Symmetric MultiProcessing

2015-02-23 Thread Friar Puck
> From: Friar Puck > Date: Sun, 21 Dec 2014 13:03:25 -0700 > > [...] > > Encouraging results are just what SOMEONE needs when going in the ring > with up to 104(!) possible demons in the guise of without-interrupts. > And that's just the runtime system. As The Reformation grinds along, I find t

[MIT-Scheme-devel] Symmetric MultiProcessing

2014-12-21 Thread Friar Puck
> From: Friar Puck > Date: Tue, 25 Nov 2014 13:22:47 -0700 > > [...] And SOMEONE should look at every global variable in the > microcode. Each deserves to be thread-local or protected by > explicit serialization. [...] Another rebase, another progress update: SOMEONE has sorted the microcode.

[MIT-Scheme-devel] Symmetric MultiProcessing

2014-11-25 Thread Friar Puck
Bless me, Schemers, for I have Schemed. It has been 19 months since my last confession and I collapse wave functions with you now only because of a potent portent of fascinating fun. Brothers, rejoice with me! I have an SMP world running multiple Scheme machines! So far they only execute an SMP

[MIT-Scheme-devel] Symmetric MultiProcessing

2014-11-12 Thread Matt Birkholz
> From: Matt Birkholz > Date: Tue, 11 Nov 2014 12:29:38 -0700 > > The following short(?) script might be useful(?) for finding references > to the 38(!) global bindings that have changed. Or maybe this is more generally applicable: grep -iE '\*default-pathname-defaults\*|\*parser-associate-pos

[MIT-Scheme-devel] Symmetric MultiProcessing

2014-11-11 Thread Matt Birkholz
The following short(?) script might be useful(?) for finding references to the 38(!) global bindings that have changed. ;;; Set working directory to your build directory, e.g.: (cd "linux-i386/src/6001/") ;;; The build directory should have cref/generate-constructors or ;;; somesuch run in it, e.

[MIT-Scheme-devel] Symmetric MultiProcessing

2014-10-26 Thread Matt Birkholz
> From: Matt Birkholz > Date: Tue, 19 Aug 2014 13:39:59 -0700 > > [...] Now is the time to say "Whoa!" The fluidization patches have been in master for almost 2 months now. If there is any wailing or gnashing of teeth going on out there, y'all are being creepy-silent about it. Just in case you

[MIT-Scheme-devel] Symmetric MultiProcessing

2014-08-19 Thread Matt Birkholz
9.2 is out there now, so I pushed the first example few of a couple dozen more patches "fluidizing" runtime/ -- replacing fluid-let with let-fluids and fluid objects. I chose let-fluids over parameterize only because it requires no new syntax. If I was certain how anyone was building from source

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2014-01-19 Thread Chris Hanson
I meant compliance with that part of R7RS. I don't expect us to have full compliance any time soon. On Sun, Jan 19, 2014 at 9:58 AM, Matt Birkholz wrote: > > From: Chris Hanson > > Date: Fri, 17 Jan 2014 22:40:01 -0800 > > > > R7RS defines parameters, which we'll eventually need to implement a

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2014-01-19 Thread Alex Shinn
On Mon, Jan 20, 2014 at 4:16 AM, Taylor R Campbell wrote: >Date: Sun, 19 Jan 2014 10:58:15 -0700 >From: Matt Birkholz > >> From: Chris Hanson >> Date: Fri, 17 Jan 2014 22:40:01 -0800 >> >> R7RS defines parameters, which we'll eventually need to implement > anyway >> f

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2014-01-19 Thread Taylor R Campbell
Date: Sun, 19 Jan 2014 10:58:15 -0700 From: Matt Birkholz > From: Chris Hanson > Date: Fri, 17 Jan 2014 22:40:01 -0800 > > R7RS defines parameters, which we'll eventually need to implement anyway > for compliance. Converting the system's bindings over to parameters is >

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2014-01-19 Thread Matt Birkholz
> From: Chris Hanson > Date: Fri, 17 Jan 2014 22:40:01 -0800 > > R7RS defines parameters, which we'll eventually need to implement anyway > for compliance. Converting the system's bindings over to parameters is > probably the right thing for a variety of reasons. Then I will stick it to master,

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2014-01-17 Thread Chris Hanson
R7RS defines parameters, which we'll eventually need to implement anyway for compliance. Converting the system's bindings over to parameters is probably the right thing for a variety of reasons. On Fri, Jan 17, 2014 at 5:49 AM, Taylor R Campbell wrote: >Date: Thu, 16 Jan 2014 20:00:54 -0700

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

2014-01-17 Thread Taylor R Campbell
Date: Thu, 16 Jan 2014 20:00:54 -0700 From: Matt Birkholz If we want SMP(?) and don't want it in a distant fork, we might just bite the bullet and replace our fluid bindings with fluid objects (like e.g. s48's). That's an assq on each reference but the thread- local values are

[MIT-Scheme-devel] Symmetric MultiProcessing

2014-01-16 Thread Matt Birkholz
I just branched from master with the following commit message. Add configure option --enable-smp. Arrange for multiple Scheme machines, "processors", (pthreads) to share the heap. Each gets its own stack and "local" heap areas. Gc-flips trace the stacks and evacuate the local hea