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.

Shmuel.

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 (
http://mrtools.svn.sourceforge.net/viewvc/mrtools/mrtools/branches/MrTools-v2/lib/MrTools/lib/MrTools/shared.pm?view=markup
) 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?


Reply via email to