Re: thread safe functions

[Ken Raeburn]

(switching to guile-devel from guile-user since I think this is more of a 
developers' issue)

On Aug 18, 2010, at 11:56, Andy Wingo wrote (quoting the manual):
>       Thus, you need to put in additional synchronizations when multiple
>    threads want to use a single hashtable, or any other mutable Scheme
>    object.

Unfortunately this applies to some internals of the implementation too.  For 
example, "set-object-property!" and friends use a hash table and assoc lists 
internally.  There's a "critical section" protecting the assoc list 
manipulation in set-object-property!, but nothing else; I doubt using it on two 
objects not already in the hash table is safe (in the sense of both concurrent 
calls taking effect, as if made serially in unspecified order), based on the 
text Andy quoted about hash tables.  But application code calling 
set-object-property! isn't explicitly operating on a mutable Scheme object (and 
a Scheme coder might reasonably assume that the properties were stored with the 
object, not in a global hash table), so the above advice from the manual 
doesn't seem to apply.

scm_c_issue_deprecation_warning and scm_c_register_extension don't look 
thread-safe to me (in the sense described above).  Both maintain linked lists 
without locking, and these aren't even implicitly Scheme objects.  Both risk 
losing the new list entries in the face of concurrent calls.

That's just from a spot check; I'm not even trying to be thorough.
And don't get me going on memory ordering models....

To be honest, I wouldn't trust libguile in a multithreaded application without 
much more careful analysis, not just of the code, but of the assumptions being 
made and whether they're actually valid for various processors (not just the 
relatively friendly x86) and compilers.  Without that sort of analysis, I think 
"use mutexes everywhere" is the only safe approach, and libguile certainly 
isn't doing that.

Ken