Re: locking with shared variables

Yes. I got you.

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]