[Israel.pm] Thread-safe module

Shmuel Fomberg semuelf at 012.net.il
Sat Feb 2 11:58:38 PST 2008


On Saturday, February 02, 2008 6:13 PM, Gabor Szabo Wrote:

>> I saw that the current recommendation in making modules thread-safe, is
>to
>> make two versions of the module. Then the main module-loader should test
>for
>> $Config{useithreads}, and 'require' the correct version. (see perlthrtut)
>
>Where did you see that?

http://perldoc.perl.org/perlthrtut.html#Thread-Safe-Modules

Anyway, I was thinking about the Perl threading model, and realized that the
main issue that made it this way was actually the scalars themselves. 

In other languages, integer is a 4 byte memory address. However access it
knows exactly where the data is, and the worse that can happen to it is
writing in parts. (where one thread writes one part of the variable, second
thread kicks in and overwrite, then the first return and write the second
part.) and there are techniques to handle this.
For more complex data structures there are thread-safe versions, which uses
locks to protect the object integrity. 

On the other hand, in Perl, the simplest scalar is a complex data structure.
Every access to it can trigger 'upgrade' and new memory allocation. (upgrade
it the action that makes an integer containing scalar to accept a string,
for example) So every access to every scalar actually requires a lock. This,
of course, will perform poorly. 
The answer was to duplicate the Perl interpreter and all its data. Now every
interpreter has its private scalars, and can play with them without locks. 

And shared variables? Perl open a secret thread that manages the shared
scalars. It means that any access to any shared variable, all share one
lock.
I was told that even changes in the reference count require that lock. Still
need to verify it.

And if we have a share complex data structure, we need another lock to
protect its integrity. 

Interesting, isn't it? 

Btw, this is probably why Java's strings can not be changed. Because if they
will be changed, you will have a complex data structure that require a lock.
Instead Java throws away the old string object, and makes a new one, with
the new value. So if some other thread is still looking on this string, the
data and the memory are still valid. This is true to all the primitive type
objects in Java, if my memory serves. 
And then the GC has to find all these thrown objects, and delete them. But
this is other problem. 

Shmuel.




More information about the Perl mailing list