2009/3/11 Neil Jerram <n...@ossau.uklinux.net>: > Neil Jerram <n...@ossau.uklinux.net> writes: > >> #<module (guile) 40376f00> >> #<directory (guile-user) 40379680> >> 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 error(s) >> FAIL: test-define-race >> >> I'm off to sleep now, so I thought I'd post what I've done in case >> others have thoughts on it or can see something wrong. > > 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... so > I hope there is an alternative.
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 have no clue as to what the overhead is. I know that the powerpc architecture implements locking primitives that are extremely fast (a few cycles); I assume Intel does as well. These are used liberally within the kernel to implement all sorts of fast atomic ops. Every now and then, some newcomer reinvents a locking system using these primitives, "for performance reasons", and posts it to some mailing list. The standard, canonical response is "you're an idiot", followed by pointers to 5 different bugs in the poster's code, and an explanation that the pthreads implementation is faster than his, and that its also debugged. (The response is less blunt when the poster is a customer of yours, and the email was delivered via some bushy-tailed executive). 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 is fully constructed, new readers will use it. The old obarray is garbage-collected in due time. I dunno if this could be applied for this case; at least we have garbage collection, which removes one major stumbling block for using COW. --linas
