Re: thread safe functions

[Ken Raeburn <raeburn@raeburn.org>]

(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