Author: Armin Rigo <ar...@tunes.org>
Branch:
Changeset: r230:3a3f0932121a
Date: 2013-06-21 17:14 +0200
http://bitbucket.org/pypy/stmgc/changeset/3a3f0932121a/
Log: Fixes probably (but the tests fail a bit unpredictably...)
diff --git a/c4/et.c b/c4/et.c
--- a/c4/et.c
+++ b/c4/et.c
@@ -661,11 +661,15 @@
commit, but if they both enter the SpinLoop()
above, then they will livelock.
- XXX This might lead both threads to cancel by
- reaching this point. It might be possible to be
+ But this might lead both threads to cancel by
+ reaching this point. For now we attempt to be
more clever and let one of the threads commit
- anyway.
+ anyway (the choice of which one looks random).
*/
+ if (d->my_lock < v) {
+ SpinLoop(SPLP_LOCKED_VALIDATE);
+ goto retry;
+ }
fprintf(stderr, "validation failed: "
"%p is locked by another thread\n", R);
return 0;
diff --git a/c4/gcpage.c b/c4/gcpage.c
--- a/c4/gcpage.c
+++ b/c4/gcpage.c
@@ -386,8 +386,15 @@
inevitable, and since it started, it popped objects out of
its shadow stack. Some popped objects might become free even
if they have been read from. But for inevitable transactions,
- we clear the 'list_of_read_objects' above anyway. */
- assert(obj->h_tid & GCFLAG_VISITED);
+ we clear the 'list_of_read_objects' above anyway.
+
+ However, some situations can occur (I believe) only in tests.
+ To be on the safe side, do the right thing and unlist the
+ non-visited object.
+ */
+ if (!(obj->h_tid & GCFLAG_VISITED)) {
+ items[i] = items[--d->list_of_read_objects.size];
+ }
}
d->num_read_objects_known_old = d->list_of_read_objects.size;
_______________________________________________
pypy-commit mailing list
pypy-commit@python.org
http://mail.python.org/mailman/listinfo/pypy-commit
