2009/3/26 Neil Jerram :
>
> - and that scm_c_eval_string consists of reading (=> symbol lookup)
> followed by evaluation (=> module obarray lookup), and that each
> scm_c_eval_string call is fast enough to be completed well within one
> time slice.
One way to stress test such situations is to call
Hi Neil,
Neil Jerram writes:
> That's an interesting idea, but to be honest I'd prefer to finish this
> work and move onto something else. Would it be OK just to reduce the
> default runtime to 2 seconds? (It wouldn't make any practical
> difference, because 10 seconds isn't normally enough to
Neil Jerram writes:
> #2 makes the symbols hash thread-safe, and it appears that this
> completely fixes the define-race problem. I don't understand why we
> apparently don't need patch #3 as well - but that's what my results
> indicate.
Maybe it's because the fragments of code passed to scm_c_
l...@gnu.org (Ludovic Courtès) writes:
> Hi Neil,
Hi Ludovic,
Many thanks for your detailed comments!
> Neil Jerram writes:
>
>> - it runs for a duration specified by environment variable
>> GUILE_TEST_DEFINE_RACE_DURATION
>>
>> - it defaults to just 10s if that variable isn't defined.
>
> E
2009/3/26 Neil Jerram :
> Linas Vepstas writes:
>
>> I reviewed patch2 as best I could,
>
> Thanks!
>
>> it looks to me like new_bucket is never released.
>> I assume that the scm_acons did a malloc, but
>> maybe not
>
> Yes, but the garbage collection will find and free it, so it's OK.
Duhh. Cle
Hi Neil,
Neil Jerram writes:
> - it runs for a duration specified by environment variable
> GUILE_TEST_DEFINE_RACE_DURATION
>
> - it defaults to just 10s if that variable isn't defined.
Even 10s is going to be slightly annoying. Another option would be to
create tens of guile-definer threads
Linas Vepstas writes:
> I reviewed patch2 as best I could,
Thanks!
> it looks to me like new_bucket is never released.
> I assume that the scm_acons did a malloc, but
> maybe not
Yes, but the garbage collection will find and free it, so it's OK.
Regards,
Neil
2009/3/25 Neil Jerram :
> #2 makes the symbols hash thread-safe, and it appears that this
> completely fixes the define-race problem.
I reviewed patch2 as best I could, but I'm cross-eyed
cause its late at night, and I don't know guile internals
well. So I'm not sure my review means much. Howev
Neil Jerram writes:
> Many thanks for your input on this. I'll go ahead with a mutex or
> rwlock. First thing is to see if it fixes the problem; if it does,
> I'll try to measure the performance impact.
Attached are 3 patches relating to thread-safe define.
#1 is Linas's test-define-race test
2009/3/25 Neil Jerram :
> Linas Vepstas writes:
>
>> Well, once you identify the section that needs locking,
>> you'll want to use an rwlock instead of a mutex. The
>> rwlock (pthread_rwlock_rdlock) allows multiple
>> simultaneous readers. The writers, however, get
>> exclusive access. (pthread_
Linas Vepstas writes:
> Well, once you identify the section that needs locking,
> you'll want to use an rwlock instead of a mutex. The
> rwlock (pthread_rwlock_rdlock) allows multiple
> simultaneous readers. The writers, however, get
> exclusive access. (pthread_rwlock_wrlock)
I forgot to comm
Hi Neil,
Neil Jerram writes:
> Neil Jerram writes:
>> Subject: [PATCH] Avoid throw from critical section, given invalid sigaction
>> call
>>
>> * libguile/scmsigs.c (scm_sigaction_for_thread): Exit critical section
>> before raising out-of-range error.
>>
>> * test-suite/Makefile.am (SCM_TE
Neil Jerram writes:
>> Yes, it's an unrelated bug. All of the places that raise errors (and
>> so exit non-locally) should exit the critical section first.
>
>> You're absolutely right. I'll leave this part out, and generate a
>> separate patch for it.
>
> Here's the separate patch...
> Subjec
Neil Jerram writes:
> I've been running Linas's define-race test program, and hitting the
> `throw from within critical section' quite a lot.
>
> We've already discussed this a couple of times:
> http://www.mail-archive.com/bug-gu...@gnu.org/msg04613.html
> http://www.mail-archive.com/guile-devel
On Sat 14 Mar 2009 15:23, l...@gnu.org (Ludovic Courtès) writes:
> Still, I would measure the impact on `module-define!' and `module-ref'
> because that's at least an additional function call.
You probably know, but at least in the VM (and I thought in the
interpreter too), the locations are comp
Hello!
Andy Wingo writes:
> Dunno, in GStreamer we found that uncontended locks are cheap cheap
> cheap. AFAIU they don't even cause context switches.
On GNU/Linux they are implemented using futexes and the kernel is not
invoked when there's no contention.
Still, I would measure the impact on
Andy Wingo writes:
> Hey Neil,
>
> On Thu 12 Mar 2009 01:53, Neil Jerram writes:
>
>> Thanks to a hint from helgrind, I think the problem might be that the
>> symbols obarray is not thread-safe. But surely using a mutex for
>> every symbol that Guile reads would be terrible for performance...
>
Hey Neil,
On Thu 12 Mar 2009 01:53, Neil Jerram writes:
> Thanks to a hint from helgrind, I think the problem might be that the
> symbols obarray is not thread-safe. But surely using a mutex for
> every symbol that Guile reads would be terrible for performance...
Dunno, in GStreamer we found t
Linas Vepstas writes:
> An alternative idea is to try to apply some principles from
> functional programming, e.g. "copy on write" (COW): when
> the obarray needs to be updated, make a copy of it. Any
> readers in other threads continue to safely use the
> original version. When the new obarray i
2009/3/11 Neil Jerram :
> Neil Jerram writes:
>
>> #
>> #
>> ERROR: ERROR: Unbound variable: x1-100499
>> Unbound variable: define
>> ERROR: Unbound variable: x4-100596
>> ERROR: Unbound variable: define
>> ERROR: Unbound variable: define
>> ERROR: Unbound variable: define
>> guile-define test cas
Neil Jerram writes:
> #
> #
> ERROR: ERROR: Unbound variable: x1-100499
> Unbound variable: define
> ERROR: Unbound variable: x4-100596
> ERROR: Unbound variable: define
> ERROR: Unbound variable: define
> ERROR: Unbound variable: define
> guile-define test case: good-bye!
> test-define-race: 2 e
Neil Jerram writes:
>> next it's on to the real problem, threadsafe define.
>
> I've been running Linas's define-race test program, and hitting the
> `throw from within critical section' quite a lot. [...]
After the patch that I posted yesterday, we finally get to the real
problem. I've tried t
Neil Jerram writes:
> next it's on to the real problem, threadsafe define.
I've been running Linas's define-race test program, and hitting the
`throw from within critical section' quite a lot.
We've already discussed this a couple of times:
http://www.mail-archive.com/bug-gu...@gnu.org/msg04613
Linas Vepstas writes:
> Perhaps I'm naive, perhaps some naming convention
> could be used to indicate that SCM_OUT_OF_RANGE
> will never return? None of the functions in the call stack
> gave any real hint that they might now return; they mostly
> looked liked ordinary functions.
As Andy has s
Hi,
Linas Vepstas writes:
> /usr/src/linux-2.6.28.4# grep -r noreturn * |wc
> 92 4397488
$ grep SCM_NORETURN libguile/*.[ch] | wc
25 1551758
Ludo'.
2009/3/6 Andy Wingo :
> Hi Linas,
>
> On Thu 05 Mar 2009 22:56, Linas Vepstas writes:
>
>> Perhaps I'm naive, perhaps some naming convention
>> could be used to indicate that SCM_OUT_OF_RANGE
>> will never return? None of the functions in the call stack
>> gave any real hint that they might now
Hi Linas,
On Thu 05 Mar 2009 22:56, Linas Vepstas writes:
> Perhaps I'm naive, perhaps some naming convention
> could be used to indicate that SCM_OUT_OF_RANGE
> will never return? None of the functions in the call stack
> gave any real hint that they might now return; they mostly
> looked lik
2009/3/5 Neil Jerram :
> Linas Vepstas writes:
>
>> I don't understand the patch.
>>
>> libguile/scmsigs.c has a SCM_CRITICAL_SECTION_START
>> at line 339, which seems to be balanced by
>> SCM_CRITICAL_SECTION_END;
>> at lines 442 and 461, right before the return from
>> the subroutine.
>>
>> So w
Hello Neil,
Thanks for the patches and tests!
Ludo'.
Linas Vepstas writes:
> I don't understand the patch.
>
> libguile/scmsigs.c has a SCM_CRITICAL_SECTION_START
> at line 339, which seems to be balanced by
> SCM_CRITICAL_SECTION_END;
> at lines 442 and 461, right before the return from
> the subroutine.
>
> So why insert this seemingly un-needed
2009/3/5 Neil Jerram :
>> Yes, it's an unrelated bug. All of the places that raise errors (and
>> so exit non-locally) should exit the critical section first.
>
>> You're absolutely right. I'll leave this part out, and generate a
>> separate patch for it.
>
> Here's the separate patch...
Err, OK
Linas Vepstas writes:
> 2009/3/5 Neil Jerram :
>>> Yes, it's an unrelated bug. All of the places that raise errors (and
>>> so exit non-locally) should exit the critical section first.
>>
>>> You're absolutely right. I'll leave this part out, and generate a
>>> separate patch for it.
>>
>> Here
Greg Troxel writes:
> Does that sound sensible; have I missed anything?
>
> Also run tests on other than Linux, with as many different OS threading
> implementations as possible. For all systems, set the threading
> libraries to the most restrictive settings, specifically aborting on any
> beh
2009/3/5 Neil Jerram :
>> Yes, it's an unrelated bug. All of the places that raise errors (and
>> so exit non-locally) should exit the critical section first.
>
>> You're absolutely right. I'll leave this part out, and generate a
>> separate patch for it.
>
> Here's the separate patch...
Looks g
Neil Jerram writes:
> Yes, it's an unrelated bug. All of the places that raise errors (and
> so exit non-locally) should exit the critical section first.
> You're absolutely right. I'll leave this part out, and generate a
> separate patch for it.
Here's the separate patch...
Neil
>Fr
Linas Vepstas writes:
> I skimmed it quickly, looks reasonable,
Thanks for reviewing!
> except for this:
>
>else
> - SCM_OUT_OF_RANGE (2, handler);
> + {
> + SCM_CRITICAL_SECTION_END;
> + SCM_OUT_OF_RANGE (2, handler);
> + }
>
> The matching SCM_CRITICA
2009/3/4 Neil Jerram :
> Here's another lock ordering fix. (For 1.8.x at least, I haven't
> checked if it's relevant to master yet.)
I skimmed it quickly, looks reasonable, except for this:
else
- SCM_OUT_OF_RANGE (2, handler);
+ {
+ SCM_CRITICAL_SECTION_END;
+
Neil Jerram writes:
> - first to address problems reported by helgrind (since I think we
> should take advantage of external tools before adding debug code to
> Guile internally)
Here's another lock ordering fix. (For 1.8.x at least, I haven't
checked if it's relevant to master yet.)
1.8.x
Hi,
Ken Raeburn writes:
> Quite a number of the projects at scan.coverity.com are GNU projects,
> including emacs and gcc; any idea if anyone from the GNU Project has
> talked to Coverity in an official capacity about getting the terms
> changed?
No idea.
> I used to use Splint, and it did fin
On Feb 12, 2009, at 16:14, Ludovic Courtès wrote:
Ken Raeburn writes:
[... Coverity ...]
I don't feel like supporting that tool. I noticed that other free
software supporters are doubtful, too:
http://blog.josefsson.org/2007/04/02/boycott-scancoveritycom/ .
The license situation might be a
Hello,
Ken Raeburn writes:
> As helgrind and NetBSD's pthread checking code work by instrumenting
> the executable and watching progress, I'd suggest also trying out
> static analysis tools if anyone has them handy. I see guile is
> already listed with Coverity's open-source scanner project; wh
Hello,
Neil Jerram writes:
> (Is something like this actually _ever_ a problem? If locks are
> always _acquired_ in the right order, how can the order of _releasing_
> ever cause a problem?)
It can't be a problem, AFAIUI. I don't think Helgrind check the
releasing order, though; the manual do
On Feb 12, 2009, at 07:55, Greg Troxel wrote:
Does that sound sensible; have I missed anything?
Also run tests on other than Linux, with as many different OS
threading
implementations as possible. For all systems, set the threading
libraries to the most restrictive settings, specifically ab
Does that sound sensible; have I missed anything?
Also run tests on other than Linux, with as many different OS threading
implementations as possible. For all systems, set the threading
libraries to the most restrictive settings, specifically aborting on any
behavior the standard says is undef
2009/2/11 Neil Jerram :
> Linas Vepstas writes:
>
>> Err, sort of, yes, unless I misunderstand. Guile 1.8 makes
>> a certain basic assumption that is splattered throughout
>> the code; it rather intentionally re-orders the order in which
>> one of the locks is taken. If I remember correctly, its
Linas Vepstas writes:
> Err, sort of, yes, unless I misunderstand. Guile 1.8 makes
> a certain basic assumption that is splattered throughout
> the code; it rather intentionally re-orders the order in which
> one of the locks is taken. If I remember correctly, its the
> "in guile mode" lock. S
Neil Jerram writes:
> * libguile/async.c (scm_async_click): Don't leave Guile mode when
> locking async_mutex. We don't need to, because none of the code
> that has async_mutex locked can block, and doing so may lead to lock
> ordering problems between async_mutex and a thread's heap_mutex
Hi Neil,
Neil Jerram writes:
> I've started working through the lock ordering and threading issues
> that we have. My plan is (with 1.8.x)
>
> - first to address problems reported by helgrind (since I think we
> should take advantage of external tools before adding debug code to
> Guile int
2009/2/11 Neil Jerram :
> I've started working through the lock ordering and threading issues
> that we have. My plan is (with 1.8.x)
>
> - first to address problems reported by helgrind (since I think we
> should take advantage of external tools before adding debug code to
> Guile internally)
>
Neil Jerram writes:
> - first to address problems reported by helgrind (since I think we
> should take advantage of external tools before adding debug code to
> Guile internally)
Here's the next one.
Neil
>From 76f55c5796f1fc7aca6c36bc57f06bab72300a94 Mon Sep 17 00:00:00 2001
From: Neil
I've started working through the lock ordering and threading issues
that we have. My plan is (with 1.8.x)
- first to address problems reported by helgrind (since I think we
should take advantage of external tools before adding debug code to
Guile internally)
- then to run Linas's define-race
51 matches
Mail list logo
