Re: Locks and threads

[Linas Vepstas]

2009/3/11 Neil Jerram <address@hidden>:
> Neil Jerram <address@hidden> 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