develooper Front page | perl.ithreads | Postings from December 2008

Re: I nead a smarter semaphore for shared variable locking

Thread Previous
Shmuel Fomberg
December 15, 2008 09:59
Re: I nead a smarter semaphore for shared variable locking
Message ID:
Hi Paul.

I'm not sure what you are trying to do here, so I can only say:
In Perl, shared variables (from threads::shared) are thread-safe. it 
means that you can mix read and writes, without weird artifacts.
Even when you have two writes, simply the last write will hold.
The only problem you can have is when you need to change the value of a 
shared variable, based on previous value. for example, $shared++.
Only in this case you need a semaphore or a lock.


Paul Robert Marino wrote:
> I've been writing threaded Perl code for a while and I've found that
> there are severe issues in sharing data between threads. Lately I've
> been trying to address some of those issues in a threaded supper class
> module I've been working on (
> ) to simplify the creation modules that use supervisor with multiple
> workers threading model . The one issue I still have is with using
> semaphores as a locking mechanism for variables. What I need is a
> locking mechanism that differentiates between a read lock and a write
> lock. Its not really a problem if multiple threads read a variable at
> once its only really a problem if two writes happen at the same time
> or a write happens during a read. Semaphores are too simple for this
> they increment and decrement within predefined limit beyond which they
> block. What is needed is actually a dual semaphore with a read lock
> and a write lock. When ever a read lock is requested the read lock
> should increment with no limit. When a write lock is requested it
> should block all new read requests until the write lock is released,
> at the same time it should block the write lock request until all of
> the previously requested read locks are released.
> There should also be some a way to specify a write locks priority behavior
>  1) opportunistic (don't block new read lock requests until the
> current read lock count = 0, in other words reads are always handled
> first regardless of the order they are received )
>  2) ordered (locks are handled strictly in the order they are received)
>  3) prioritized (write locks are always granted before read locks
> regardless of the order they are received).
> Does any one have any comments, suggestions or additional requirements
> (in case I need to write some thing from scratch) on this subject?

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About