Talk:Lock (computer science)

From Wikipedia, the free encyclopedia

	This article is within the scope of WikiProject Computer science, which aims to create a comprehensive computer science reference for Wikipedia. Visit the project page for more information and to join in on related discussions.
Start	rated as Start-Class on the assessment scale
Mid	rated as Mid-importance on the assessment scale

Contents 1 The code example in the article doesn't guarantee mutual exclusion 2 Lock Modality? 3 This subject should be given greater importance in the foregoing graphic schematic and implied editorial perception / projection. 4 "They cause blocking" as a disadvantage?

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

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)

[edit] Lock Modality?

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)

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

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)

[edit] "They cause blocking" as a disadvantage?

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)