Talk:Lock (computer science)

message: 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)
thread_title:  The code example in the article doesn't guarantee mutual exclusion 

message: 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 , , or  could serve as useful references?
--Kevinoid 14:32, 28 November 2006 (UTC)
thread_title:  Lock Modality? 

message: 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)
thread_title:  This subject should be given greater importance in the foregoing graphic schematic and implied editorial perception / projection. 

message: 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)
thread_title:  "They cause blocking" as a disadvantage? 

message: "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)
thread_title:  rendez-vouses? 

message: 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)
thread_title:  There's a lot of redundancy in Section 4:  The problems with Locks 

message: 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)
thread_title:  Citation needed??? 

message: 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:
*Added archive https://archive.is/20130102015335/http://www.25hoursaday.com/CsharpVsJava.html to http://www.25hoursaday.com/CsharpVsJava.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 03:36, 25 May 2017 (UTC)
thread_title:  External links modified 

message: 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:
*Added archive https://web.archive.org/web/20110620203242/http://www.futurechips.org/tips-for-power-coders/parallel-programming-understanding-impact-critical-sections.html to http://www.futurechips.org/tips-for-power-coders/parallel-programming-understanding-impact-critical-sections.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 00:23, 5 January 2018 (UTC)
thread_title:  External links modified