This way it makes sense. You lock the variable locally as you work with it / modify it. I was not thinking of this concept. I concentrated more on my problem to have a scheduler thread that distributes the work among some worker threads. (And even a bit more complex). Therefore i abuse the shared variables to submit signals. That means I lock the variable once at the start of the thread and if I'm ready to receive a signal / data, then I do a cond_wait on the variable.
And the submiting jobs are only allowed to do a short 'local' lock for the variable. E.g. ' {lock($$slave_ref); $$slave_ref = $value; cond_sig($$slave_ref); }'
Thanks and Regards, Stefan
Mike Pomraning wrote:
On Thu, 20 Nov 2003, Stefan Bergler wrote:
It is sufficient to have ONE lock within ONE thread, to own the shared
variable as long as this lock is within the scope of the thread. This
lock is kind of inheritet by any called sub function and it does not
make a difference if the subfunction does an additional lock or not. (I
would rather say, the subfunctions should not do additional locking if
the shared variable is already locked.)
It makes a difference to the design, if the subfunctions are may be called independently:
my $m : shared; sub do_this { lock($m); $m++; } sub do_that { lock($m); $m *= 2; do_this(); }
I might call "do_this" myself, or implicitly from within "do_that", and it must hold the lock in either case. (Along those lines, X/Open offers PTHREAD_MUTEX_RECURSIVE and win32 has re-enterable CriticalSections, I believe.)
Regards,
Mike
-- Infineon Technologies - CL DAT LIB CL - lib.muc.infineon.com/lib-cl/ Stefan Bergler Tel. +49 89 / 234 28601 Postfach 800949 Fax. +49 89 / 234 955 6230 D-81609 Muenchen [EMAIL PROTECTED]
