If there would be only readers, locking would not be necessary. When
there is a single concurrent writer, locking is necessary, otherwise the
reader could see inconsistent state (e.g. partial writes in the
database, or in the file system, or in the interaction between these).
Most systems use per default mutex-locks. Common optimizations
distinguish between read-locks and write-locks, which allow multiple
concurrent readers.
The Tcl thread package (part of tcl 8.6) supports rw-locks
-g
Am 18.11.15 um 13:01 schrieb Rainer Müller:
On 2015-11-18 12:52, René J.V. Bertin wrote:
I agree that there should be a lock that prevents concurrent access
to the registry database, as that's something that appears likely to
lead to registry corruption. If the registry lock were to be set when
doing an (un)install or (de)activate, it'd be set very quickly when
issuing `port uninstall` or `port deactivate`, right?
The problem is the time between the decision and when it is actually
executed. The state should not change between that or you will run into
problems.
For example, see this report from before we had this locking:
http://trac.macports.org/ticket/19935
As I said, there is potential to allow certain operations with
fine-grained locking, but it requires more planning to get this right.
Just enforcing serialization of all actions that modify the registry is
the easy solution that works in most cases.
Rainer
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
