Class with Thread

pg has asked for the wisdom of the Perl Monks concerning the following question:

Monks, I feel pretty bad. Couple of monthes ago, I worked on project, the purpose is to create some API library. I made three sets of libraries in three languages, C, Java and Perl. C and Java versions are multi-threaded, but not the Perl version.

We sort of prematurely determined that Perl does not support thread, at least not real thread. Today, I installed 5.8.0, went through the doc, and realized Perl does have thread, lock, and even cond. Can any one share some experience with me, about its functionality, stability and performance? I should have tried it, had I known.

I especially care how well Perl thread works with OO. When you apply lock on a hash ref, it does not lock the hash itself. I am not saying this is not reasonable, but it does worry me, as Perl class is, most of the time, a hash ref, well even array ref, it is the same thing.

Of course, when you lock a hash ref, you don't want to lock the whole hash, as different threads need to access different elements of that hash at the same time. Hash is just an aggregation, elements are loosely coupled. But class is different, whatever in that "class hash", they are tight coupled (if they are loosely coupled, you have to look at the way you define your classes), you would expect that, most of the time, a lock on an object should lock the whole object, and the user of the object should not care the implementation of the class. It would be nice, if Perl does provide a predefined way to do this, instead of leaving this totally to each monk.

Also there is this fact, that Perl is not solely OO, there is no root class, like Java's "object", and thread functionality is not implemented first in the root class, and then inherited by all.

Comment on Class with Thread

Replies are listed 'Best First'.
Re: Class with Thread by Zaxo (Archbishop) on Nov 16, 2002 at 04:49 UTC
I'm pretty new to this, too, but this is what I've picked up. An object can be implicitly locked for the duration of a method by the definition syntax: `sub some_method : method : locked { my $self = shift; # ... }` [download] See attributes. By default in 5.8 ithreads, variables are not shared and no locking is needed. Each thread has its own copy of the variables. See threads. If you want shared variables you need to `use threads::shared;` which makes the `shared` attribute available, and provides share() to set the attribute at runtime and `lock()` to hold it stable. Sharing reaches one reference level deep, so you can lock a reference `$foo = \@foo` with `share(\$foo)` and avoid locking the underlying structure. For objects, `share($foo)` locks the `@foo` array, too. The perlthrtut doc is a great way to get started with this stuff. I quote from it: If you have experience with other thread implementations, you might find that things aren't quite what you expect. It's very important to remember when dealing with Perl threads that Perl Threads Are Not X Threads, for all values of X. They aren't POSIX threads, or DecThreads, or Java's Green threads, or Win32 threads. There are similarities, and the broad concepts are the same, but if you start looking for implementation details you're going to be either disappointed or confused. Possibly both. After Compline, Zaxo	[reply] [d/l]

Replies are listed 'Best First'.

Re: Class with Thread
by Zaxo (Archbishop) on Nov 16, 2002 at 04:49 UTC

I'm pretty new to this, too, but this is what I've picked up.

An object can be implicitly locked for the duration of a method by the definition syntax:

sub some_method : method : locked {
    my $self = shift;
    # ...
}
[download]

attributes

By default in 5.8 ithreads, variables are not shared and no locking is needed. Each thread has its own copy of the variables. See threads. If you want shared variables you need to use threads::shared; which makes the shared attribute available, and provides share() to set the attribute at runtime and lock() to hold it stable.

Sharing reaches one reference level deep, so you can lock a reference $foo = \@foo with share(\$foo) and avoid locking the underlying structure. For objects, share($foo) locks the @foo array, too.

The perlthrtut doc is a great way to get started with this stuff. I quote from it:

If you have experience with other thread implementations, you might find that things aren't quite what you expect. It's very important to remember when dealing with Perl threads that Perl Threads Are Not X Threads, for all values of X. They aren't POSIX threads, or DecThreads, or Java's Green threads, or Win32 threads. There are similarities, and the broad concepts are the same, but if you start looking for implementation details you're going to be either disappointed or confused. Possibly both.

After Compline,
Zaxo

[reply]
[d/l]