Diskussion:Lock

Auf dieser Seite werden Abschnitte ab Überschriftebene 2 automatisch archiviert, die seit 14 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter Archiv.

Unlocking

Es gibt zumidnestens für Windows Programme, die den Lock aufheben können, d.h. die Datei freigeben können. Das funktioniert nach meiner Erfahrung immer, außer wenn das Programm zum unlocken nicht erkennt, dass die Datei gelockt wird und sie deshalb irrtümlicherweise für freigegeben hält. Es kann auch vorkommen, dass der Prozess, der die Datei gelockt hat das sofort nach dem Unlock wieder tut. Programme, die Locks aufheben können sind für Windows unter anderem Unlocker und Process Explorer, letzteres ist sogar von Microsoft.

Ich denke man sollte im Artikel etwas darüber reinschreiben, wie diese Programme funktionieren. --MrBurns 16:49, 23. Okt. 2008 (CEST)

Nachtrag: bei Process Explorer heißt die entsprechende Funktion "Close Handle" weil dabei eben der/das entsprechende Handle geschlossen wird. Aber damit ist antürlich auch der Lock weg. --MrBurns (Diskussion) 18:47, 13. Dez. 2012 (CET)

Multilocking

Multi-Locking gehört zum pessimistischen Locking<!-- und ermöglicht ein Deadlock freies Programmieren // bitte belegen -->. Beim MultiLock werden die Locks gleich am Anfang des Synchronisierungsblocks reserviert und bilden einen MultiLock.<!-- Bei MultiLocks können keine Dead-Locks entstehen, weil ein MultiLock nur dann gestartet wird, wenn alle benötigten Locks verfügbar sind. // also evtl. nie, was man auch "Deadlock" nennt? --> [Auszug aus dem Artikelquelltext]

Ich hab von Muti-Locks zwar noch nie was gehört, aber die Erklärung klingt für mich schlüssig. Ein Deadlock kann nur entstehen, wenn zwei Locks vorhanden sind, die an zwei Stellen in umgekehrter Reihenfolge angefordert werden. So kann Thread1 Lock1 halten und auf Lock2 warten, wohingegen Thread2 Lock2 hält und auf Lock1 wartet. Das ist ein Deadlock. Ein Muti-Lock scheint nun ein Mechanismus zu sein, der sicher stellt, dass entweder beide Locks erworben werden oder keines. Damit ist die Situation quasi isomorph zur Situation, dass nur ein Lock vorhanden ist und damit kann es keine Deadlocks geben. Die zweite Coffman-Bedingung ist einfach nicht mehr gegeben. Klingt absolut logisch. Wie so ein Multilock aber verwendet werden können soll (i.d.R. fordert man zwei Locks ja nicht einfach in zwei aufeinanderfolgenden Zeilen an, sondern implizit über geschachtelte Methodenaufrufe) erschließt sich mir nicht. Könnte auch irgend ein Forschungsprojekt sein, oder so. Keine Ahnung. An Belegen und Beispielen wäre ich auch interessiert... --Der Hâkawâti ✉ 13:07, 12. Dez. 2012 (CET)

Ich wäre für deadlock>>triplelock>>pentalock>>>multilock ;) (nicht signierter Beitrag von 93.214.227.12 (Diskussion) 04:41, 12. Jun. 2013 (CEST))

Der Compiler könnte zur Compile-Zeit die Lock-Anforderungen einer Methode auf die aufrufende "Elternmethode" „vererben“, bis zu der Methode am nahesten an .main, die noch selbst Locking betreibt.

main
 funkA
  funkAB      will Lock_on_Device1
   funkABC
    funkABCD  will Lock_on_Device2

Dann vererbt funkABCD ihre Anforderung an funkABC und funkAB; funkAB muss dann einen Multilock auf Dev1 und Dev2 machen.

--arilou (Diskussion) 13:38, 6. Mai 2019 (CEST)

Locks in read- und write-locks zu unterteilen ist falsch

Die Unterteilung ist falsch und irreführend.

Richtig wäre eine Unterteilung in Shared (statt read) und Exclusive (statt write) Locks, was der Autor wahrscheinlich auch meinte.

--79.247.144.74 14:47, 7. Feb. 2013 (CET)

Ich sehe da keinen Unterschied. Und auch kein "Irreführungs-Potential". Also keine Notwendigkeit, am Artikel etwas zu ändern.

Evtl. kann dem Artikel hinzugefügt werden, dass mitunter "read lock" auch "shared lock" genannt wird, und "write lock" auch mal "exclusive lock" heißen kann.

--arilou (Diskussion) 15:37, 7. Feb. 2013 (CET)

Ich habe es mal als Klammeranmerkung dazu geschrieben, mMn. hilft die Unterscheidung shared/excl doch etwas beim Verständnis. --Plankton314 (Diskussion) 23:36, 12. Jun. 2013 (CEST)