bugKawa - Bugs: bug #11801, fluid-let problems in the presence...

 
 

bug #11801: fluid-let problems in the presence of threads

Submitted by:  Dean Ferreyra <dferreyra>
Submitted on:  Tue 01 Feb 2005 04:20:31 AM UTC  
 
Category: Scheme languageSeverity: 3 - Normal
Item Group: Unexpected resultStatus: Fixed
Privacy: PublicAssigned to: Per Bothner <bothner>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sat 12 Feb 2005 07:53:42 AM UTC, comment #4:

I checked in a fix. I use a ThreadLocation object (which contains a ThreadLocal) to map a key and the current thread to a thread-specific Location.
This is equivalent (more or less) to looking up the key in the current thread's environment for each access, but we cache a thread-specific Location handle in a ThreadLocal.
This is a less efficient than the previous solution (where we cache the thread-specific Location) in a field, but (as discussed in comment #3) that solution is problematical when multiple threads are involved. Some optimizations may be possible later, if it seems worthwhile.

Per Bothner <bothner>
Project AdministratorIn charge of this item.
Fri 11 Feb 2005 05:16:07 AM UTC, comment #3:

I think I understand the problem. It's something I'd been vaguely concerned about before, without really thinking things through it properly.

There is by default one Environment per thread, and it maps a Symbol (and a property we can ignore here) to a Location object, which contains the actual value. Hence a Location is also normally per-thread, but a Location can indirect to another Location, possibly belonging to the parent thread.
The compiler caches the Locations in the fields of the module. My assumption was that if you used multiple threads, you'd have multiple module instances. But this fails in two ways:

(1) If you use module-static. We need to split up module-static into two options: "module-single" (assume a single thread) and "module-static" (a shared module, and global module values, but with per-thread "dynamic environments").
(2) Even with module-static #f you get a problem if a call to future passes the current module instance to the child thread, which then reuses the parent's cached Location objects. That is the issue with the test-case.

I've been pondering how srfi-39 "parameter objects" relate to fluid variables. I think a solution to the current problem is for the module to cache "parameter objects" (in static fields) instead of thread-specific Location objects. I'm working on that.

Per Bothner <bothner>
Project AdministratorIn charge of this item.
Wed 09 Feb 2005 07:04:43 PM UTC, comment #2:

I thought I'd give it another try. I'm attaching a more deterministic test case that fails for me. It staggers (in time) two threads' access to a dynamic variable assigned through fluid-let. At least when I run it, I get the result '(2 #f) instead of '(1 2), as if the dynamic variable is being shared by the two threads.

This test passes with an older 1.7.90 version of Kawa.

Anonymous
Sat 05 Feb 2005 03:52:08 AM UTC, comment #1:

I ran the test, and it passed.
Of course that doesn't prove there isn't a bug!
I looked at your code, and I would expect it to work.
I do plan to change how fluids are implemented, to use a ThreadLocal that points to a Location. (The indirection is needed for sharing.) That might fix the problem, or not.
But even if the problem is no longer apparent, there might still be an underlying bug that might bite in some other way, so it would be a good idea if we could determine the problem with the existing code.

Per Bothner <bothner>
Project AdministratorIn charge of this item.
Tue 01 Feb 2005 04:20:31 AM UTC, original submission:

The attached patch adds a test to the testsuite that is a distilled version of a regression test we (at Merced Systems) have that fails when I compile it using the latest Kawa sources. For me this test mostly fails, though occasionally it passes.

The test starts a bunch of threads and each is eventually supposed to return the value representing its starting order. Before returning its value, the thread runs the value through a dynamic variable: first it assigns the value with fluid-let, and then it calls a function to read back the value of the dynamic variable. I believe each thread should get back the value it set through fluid-let, but sometimes it gets back the value of another thread, sometimes the initial value of #f, and sometimes even #!null.

I have tried this against a version of 1.7.90 that we're using and it's passed every time I've tried it.

I hope I'm not overlooking some order-of-evaluation issue here.

Dean Ferreyra <dferreyra>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #2532:  threads2.diff added by None (1KiB - application/octet-stream - Patch to testsuite with more deterministic test)
file #2471:  threads.diff added by dferreyra (1KiB - application/octet-stream - Patch to testsuite to exercise dynamic variables with threads)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 5 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sat 12 Feb 2005 07:53:42 AM UTCbothnerStatusNone=>Fixed
  Open/ClosedOpen=>Closed
Wed 09 Feb 2005 07:04:43 PM UTCNoneAttached File-=>Added threads2.diff, #2175
Sat 05 Feb 2005 03:52:08 AM UTCbothnerAssigned toNone=>bothner
Tue 01 Feb 2005 04:20:31 AM UTCdferreyraAttached File-=>Added threads.diff, #2133

Back to the top


Powered by Savane 3.1-cleanup1