+2005-11-08 Frank Ch. Eigler <fche@redhat.com>
+
+ * translate.cxx (c_unparser::visit_foreach_loop): With PR 1275
+ done, add back read lock around foreach loop. Add a write lock
+ around preceding sort operation. Leave a race condition window. :-(
+
2005-11-08 Frank Ch. Eigler <fche@redhat.com>
* translate.cxx (mapvar::exists): Correct some more.
// initialization
- // XXX: until bug #1275 is fixed, any reference into a foreach()-iterated
- // array is an instant deadlock. For now, don't lock around foreach(),
- // and hope that no concurrent probe handler will modify this array.
- //
- // varlock_r guard (*this, mv);
-
// sort array if desired
if (s->sort_direction)
- o->newline() << "_stp_map_sort (" << mv.qname() << ", "
- << s->sort_column << ", " << - s->sort_direction << ");";
+ {
+ varlock_w sort_guard (*this, mv);
+ o->newline() << "_stp_map_sort (" << mv.qname() << ", "
+ << s->sort_column << ", " << - s->sort_direction << ");";
+ }
// NB: sort direction sense is opposite in runtime, thus the negation
+ // XXX: There is a race condition here. Since we can't convert a
+ // write lock to a read lock, it is possible that another sort or update
+ // may get sandwiched between the release of sort_guard and the
+ // acquisition of guard.
+
+ varlock_r guard (*this, mv);
o->newline() << iv << " = " << iv.start (mv) << ";";
// condition