On Thu, 03 May 2001 13:35:21 EDT, Benjamin Sugars wrote:
>Are you saying that you see the locking happening transparently from
>user-code?
No. I'm talking about how the guts access the shared data. This needs
to be made safe irrespective of what the programmer attempts to do
(i.e. can't have coredumps just because they didn't lock something
they should have).
lock() will still exist as a builtin function. It's function
is independent of the locks in the magic callbacks. lock()
will be used by the Perl programmer to avoid deadlocks.
>Ie.,
> our $sv : shared = "foo";
> # Start some threads here, then...
> print $sv; # read-only, no lock according to above?
> $sv = "bar"; # locks $sv for read/write
>
>Would this not litter the core with lots of tests for sharedness and
>subsequent SvLOCKing?
Nope. The only gratuitous locking will be in the magic callbacks.
All other locking overhead will come from lock(), which will be
at the control of the programmer.
>Also, it would seem to be prone to race conditions
>or deadlock unless the relevant operations could be made atomic.
There will be no race conditions if everything is implemented correctly.
Deadlocks are always possible iff they didn't use lock() properly.
Note that lock() need not be used if the control flow logic does not
demand it.
>If so, I would think it better to put the onus on the programmer to guard
>entry to such critical sections, rather than trying to do it
>transparently.
I don't like making the programmer responsible for avoiding coredumps
in the guts.
Sarathy
[EMAIL PROTECTED]
