Jump to content

Talk:Lock (computer science)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

The code example in the article doesn't guarantee mutual exclusion

[edit]

I removed the following code example from the article as it doesn't solve the atomicity problem: 

 while (1)
 { /* loop until lock is obtained */
     if (lock == 0)
     { /* lock not set */
         lock = myPID; /* set lock with my process ID */
         sleep(1); /* wait for a short time */
         if (lock == myPID) break; /* we still have the lock */
     }
     /* we still don't have the lock */
     sleep(someTime); /* wait for some period of time */
 }
 //Critical Section

Let's assume Process A and B are executing. A executes, checks the if guard that lock==0, proceeds then does a context switch. B then checks the lock, confirms it's open, proceeds and does a context switch. A then sets lock to its PID, and sleeps. There's no guarantee that B will wake up next and overwrite the lock variable. A wakes up 1s later, checks that it still does have the lock, breaks and enters the critical section. At some point it does a context switch. B then proceeds as normal; it overwrites the lock variable, sleeps, rechecks it has the lock, then enters the critical section as well.

--Chozan 02:23, 12 November 2005 (UTC)[reply]

Lock Modality?

[edit]

Along with the ideas of granularity, perhaps there could be some discussion of the modality of locking schemes (shared locks, exclusive locks, intent locks) and the obligatory table of the compatibility of different locks. I don't feel competent enough to write this section myself, but if anyone with familiarity in the subject would be interested, perhaps [1], [2], or [3] could serve as useful references?

--Kevinoid 14:32, 28 November 2006 (UTC)[reply]

This subject should be given greater importance in the foregoing graphic schematic and implied editorial perception / projection.

[edit]

Modern computer systems and applications CANNOT FUNCTION PROPERLY without correct locking mechanisms, including the so-called "lock-free" solutions. The art has advanced beyond local ad hoc stand-alone programs. All professional systems designers and programmers must consider asynchronous concurrency, coherency, serialization, multiprocessing environments and application integrity.

Although this particular article does not necessarily, and probably is not intended to, nor needs to, cover the entire ground, it is nonetheless a particularly significant entry point into the Wikipedia literature, and deserves the suggested upgrade.

Lor 04:11, 7 November 2007 (UTC)[reply]

"They cause blocking" as a disadvantage?

[edit]

In section The problems with locks, it lists the following as one of the disadvantages:

They cause blocking, which means some threads/processes have to wait until a lock (or a whole set of locks) is released.

Well, that's pretty much the purpose of locks (to block threads/processes until some conditions are met), isn't it? I say we remove this, but I'll wait for opinions.

--PoisonedQuill (talk) 10:09, 13 June 2008 (UTC)[reply]

Not really, as I understand it, locks are just for mutual exclusion, not condition synchronization (well, I guess we could argue about mutual exclusion being the same as having a condition that says that only one process at a time can execute in a given critical section). Nevertheless, I agree with you in that having to wait is not a problem caused by using locks, but by using a solution that has a critical section. I think the second item,

Lock handling adds overhead for all access to a resource, even when the chances for collision are very rare. (However, any chance for such collisions is a race condition).

is trying to say pretty much the same thing. I'd add "Because threads have to wait to obtain a lock," before "lock handling adds overhead for all...", remove the first item, and leave it at that. Facuq (talk) 02:49, 14 May 2009 (UTC)[reply]


Locking mechanisms are an advantage because they enable the implementation of "critical sections". Critical sections are inevitable in any environment where resources (memory locations, devices, files, etc.) must be shared asynchronously, for example, the printer on your network. Critical sections are not a problem either, since they manage shared resources. The blocking of threads is an unavoidable consequence, not a "problem" - if you consider a problem as something that might have a solution.

There is a problem, though, and that is there must be sufficient resources - exclusively dedicated memory, real or virtual - available for the locking mechanisms to maintain their state information in response to a varying number of contemporaneous invocations, without which the mechanisms will fail, or "crash" bringing down everything depending on them and bringing down the operating region in which they reside. "Failure" is better than crashing, which means a proper locking mechanism ought to be able to return an "unable to obtain lock for <whatever> reason" status to the critical section in the application, which ought to be able to handle that situation gracefully.

The logical design of an application requires these considerations from the very root of conception.

Lor (talk) 16:05, 10 October 2009 (UTC)[reply]


@PoisonedQuill, you are right. That's what locks are for if you want to understand them at the lowest possible level. At a higher level though, we use locks to implement mutual exclusion, and we use mutual exclusion to guarantee certain invariants in a program. If the program can be re-designed to solve the same problem, but with invariants that require fewer mutexes or no mutexes at all, then it will out-perform the original program. 206.210.75.84 (talk) 15:14, 22 May 2012 (UTC)[reply]

I combined the "blocking" bullet with the "wait forever" bullet, as they are just different aspects of the same issue. On the bullet reading: "Lock handling adds overhead for each access to a resource, even when the chances for collision are very rare. (However, any chance for such collisions is a race condition.)"... The parenthetical statement makes no sense. Locks help avoid race conditions, so a chance for such a collision would be a race condition if you failed to use the lock. Yes, deadlock can be a problem, but that is what lock-dependency checkers are for. Lots of people talk about composability problems with locking, but just you try composing a pair of transactions with (say) and RPC operation between them. Some work required to achieve NPV here! PaulMcKenney (talk) 17:03, 17 November 2013 (UTC)[reply]

rendez-vouses?

[edit]

"Ada is probably worth looking at too for a comprehensive overview, with its protected objects[12][13] and rendez-vouses."

rendez-vouses? really? I'm not a french expert, but shouldn't this just be rendez-vous?

Maybe someone who is more confident in french can confirm this?

Chaos.squirrel (talk) 06:29, 23 June 2010 (UTC)[reply]


I'm French but I've also checked the Oxford dictionary. "rendezvous" doesn't have a hyphen and doesn't take "es" in the plural form.

I've made the change.

Togamaru (talk) 23:51, 26 October 2011 (UTC)[reply]

There's a lot of redundancy in Section 4: The problems with Locks

[edit]

I don't have time to re-write it, but almost every one of the bullet points under that heading seems to overlap with several of the others. E.g.;

  • They cause blocking, which means...
  • If one thread holding a lock dies, stalls/blocks or goes into any sort of infinite loop,...
  • Convoying..., if a thread holding a lock is descheduled,... — Preceding unsigned comment added by 206.210.75.84 (talk) 15:02, 22 May 2012 (UTC)[reply]

Citation needed???

[edit]

It's weird that the following statement needs a citation: "This subtlety can increase the chance that a programmer will unknowingly introduce a deadlock". If an application's locking logic is complex, it may have deadlocks that in some cases can not be avoided (and must be detected). If the logic is simple, only bugs can lead to deadlocks. I didn't write that statement, but I can't beilive that someone is waiting for a citation. — Preceding unsigned comment added by 151.21.12.97 (talk) 17:56, 1 June 2013 (UTC)[reply]

[edit]

Hello fellow Wikipedians,

I have just modified one external link on Lock (computer science). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:36, 25 May 2017 (UTC)[reply]

[edit]

Hello fellow Wikipedians,

I have just modified one external link on Lock (computer science). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 00:23, 5 January 2018 (UTC)[reply]

Retrieved from "https://wiki.riteme.site/w/index.php?title=Talk:Lock_(computer_science)&oldid=1203730588"