neumann at wu.ac.at
Wed Nov 18 04:44:23 PST 2015
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
The Tcl thread package (part of tcl 8.6) supports rw-locks
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
> For example, see this report from before we had this locking:
> 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.
More information about the macports-dev