in reply to Re^2: Thread::RWLock for 5.8 threads ?
in thread Thread::RWLock for 5.8 threads ?

Yes, it would need more than that one line changing, but something like this ought to be close:

package threads::RWLock; use threads; use threads::shared; BEGIN { $VERSION = do { my @r = (q$Revision: 1.2 $ =~ /\d+/g); sprintf "%d +."."%02d" x $#r, @r }; # must be all one line, for MakeMaker } =head1 FUNCTIONS AND METHODS =over 8 =item new C<new> creates a new rwlock. The new rwlock is unlocked. =cut sub new { my $class = shift; my %self : shared; my $self = bless \%self, $class; my %anon : shared; $self->{locks} = 0; $self->{locker} = \%anon; $self->{writer} = 0; return $self; } =item down_read The C<down_read> method obtains a read lock. If the lock is currantly held by a writer or writer are waiting for the lock, C<down_read> bloc +ks until the lock is available. =cut sub down_read { my $self = shift; lock $self; if ($self->{locker}->{threads->self->tid}++) { return; } cond_wait $self until $self->{locks} >= 0 && $self->{writer} == 0; $self->{locker}->{threads->self->tid} = 1; $self->{locks}++; } =item up_read Releases a read lock previously obtained via C<down_read>. =cut sub up_read { my $self = shift; lock $self; if (--$self->{locker}->{threads->self->tid} == 0) { $self->{locks}--; if ($self->{locks} == 0) { cond_broadcast $self; } } } =item down_write Obtains a write lock from the rwlock. Write locks are exclusive, so no other reader or writer are allowed until the lock is released. C<down_write> blocks until the lock is available. =cut sub down_write { my $self = shift; lock $self; $self->{writer}++; cond_wait $self until $self->{locks} == 0; $self->{locks}--; } =item up_write Release a write lock previously obtained via C<down_write>. =cut sub up_write { my $self = shift; lock $self; $self->{writer}--; $self->{locks} = 0; cond_broadcast $self; } =back =head1 SEE ALSO the Thread::Semaphore manpage =head1 AUTHOR Andreas Ferber <aferber@cpan.org> Tentatively modified for iThreads by BrowserUk@perlmonks =cut 1;

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^4: Thread::RWLock for 5.8 threads ?
by renodino (Curate) on Oct 24, 2005 at 17:38 UTC
    Yep thats what I've come up with, tho I'm trying to write it as an abstract class that Thread::Queue::Queueable objects derive from. And then I need to figure out where/how to CPAN it.
      And then I need to figure out where/how to CPAN it.

      Yep. And there lies another minefield.

      You'll see that I chose to use threads::RWLock as a working title.

      That would get frowned upon by the "powers that be", because it has a all-lower first element to the name, but quite frankly, continuing to stick threads-related modules in the Thread::* namespace just invites further and continued confusion over what works with what and why. Like Perl's threads need another barrier to use.

      But then I guess the "powers-that-be" that makes these stupid decisions are probably all hardcore 'we don't need no stinkin' threads'-people anyway.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        Yeah, namespace is an issue. In the interest of GOWI, I'll probably bury it inside the Thread::Queue::Duplex bundle. Tho maybe "Thread::Resource::ReadWrite" might be a good namespace, so anything else related to sharing resources among threads has a root. I'm already considering an alternate locking algorithm that permits upgrading read to write locks, or downgrading writes to reads; as currently implemented, T::RWLock requires a reader to unlock before it could get a write lock.