Talk:Semaphore (programming)

message: Could anyone provide supporting information for the statements in the "semaphores today" section?
I fail to understand why semaphores should be considered as bad as goto.
The only info I was able to google did not clarify it (such as: preferring the synchronize keyword for the Java language, the difficulty of the use of semaphore).
Thanks!
--Fr3d3r1c 17:50, 27 Feb 2005 (UTC)
thread_title: Supporting information

message: Yes, Dijkstra really wrote "try-and-decrease," not "try-to-decrease." That's an idiomatic English expression; for example, "I'm going to try and improve this article a bit." However, "try-to-decrease" is a much less ambiguous phrase. (A non-native English speaker, or even a paranoid native speaker, might sensibly ask, "Try what, and (then) decrease?") So I've made the change in the article. I don't think it's appropriate to keep only the "try-to-decrease" translation, since that's not what Dijkstra actually wrote. --Quuxplusone 07:18, 3 March 2006 (UTC)
thread_title:  Try-and-decrease 

message: Someone should mention why semaphores can't handle deadlocks: because a random thread gets unblocked when V is called (so the threads don't wake up in FIFO order; it is theoretically possible that a thread never wakes up if other threads call P all the time and get woken up first). --Bernard François 17:39, 4 January 2007 (UTC)
thread_title:  deadlocks 

message: What's is up with the dutch example? I understand this might refer to the original article introducing these semaphores, but these names are not used anywhere anymore that I know of. I have been an a teacher for 5 years in multiprogramming, and we have used 3 different books. All the books use signal() and wait() instead of P and V. Could we please update it to reflect modern and more self-documenting code? Carewolf (talk) 12:26, 11 December 2007 (UTC)
replies: text: I agree that P and V are bad function names. But signal() and wait() are more associated with condition variables, aren't they? (also notify() instead of signal() as a variant) There is also acquire(...) and release(...) (e.g. java.util.concurrent.Semaphore), and probably lots of other names. But this is exposition code, not library code -- we should probably select more verbose, descriptive names, such as WaitForUnits(s, n) and ReturnUnits(s, n). (And maybe include a short list of names for them commonly seen in libraries) Hurkyl (talk) 04:37, 29 December 2007 (UTC)
replies: text: Ah, I see there is already a short list; I missed it while skimming the page. Maybe it should be made more prominent? Hurkyl (talk) 04:40, 29 December 2007 (UTC)

text: I suggest making acquire and release the 'official' verbs on this page (to be used in examples etc.), since they are probably the most descriptive and widely used words associated with semaphores and the likes. P and V are pretty much the worst names you can use on an encyclopedic page, regardless of their historical value. --93.125.228.122 (talk) 09:40, 4 September 2009 (UTC)
replies: text:  I'd be very happy with acquire and release.  P and V are remarkably unhelpful. Dan aka jack (talk) 17:43, 25 April 2011 (UTC)
replies: text: It's perfectly fine to use newer terminology in addition to the original.  But the original is P and V, for the reasons given.  Yes, those aren't all that helpful (unless you speak Dutch).  But the article needs to talk about history from the beginning.  It should not limit itself to the descriptive terms and in the process lose part of the history. Paul Koning (talk) 21:09, 18 August 2015 (UTC)
thread_title:  P and V ??? 

message: As written, the counting semaphore admits deadlocks if three separate threads each attempt to acquire then release N permits and the semaphore has less than 2N available. A problematic sequence of operations is:
 Semaphore S
 Init(S, 3) // s == 3
 Thread 1 calls P(S, 2)
 Thread 1 passes the first wait
 Thread 1 decrements S by 2  (S == 1)
 Thread 1 passes the second wait
 Thread 2 calls P(S, 2)
 Thread 3 calls P(S, 2)
 Thread 2 passes the first wait
 Thread 3 passes the first wait
 Thread 2 decrements S by 2  (S == -1)
 Thread 3 decrements S by 2  (S == -3)
 Thread 1 calls V(S, 2)
 Thread 1 increments S by 2  (S == -1)
 Thread 2 blocks at the second wait
 Thread 3 blocks at the second wait
After this sequence of operations, the semaphore is permamently blocked, and threads 2 and 3 will never continue. The paragraph describing the counting semaphore seems to assume that there is some implicit synchronization happening similar to java's synchronized methods.
I propose that the example be rewritten with a condition variable to explicitly provide synchronization, or something similar. If nobody objects, I may do it myself. Hurkyl (talk) 09:22, 1 January 2008 (UTC)
replies: text: The problem is that the code as is possesses one of the necessary conditions for a deadlock - the process, attempting to decrement the semaphore simultaneously holds resources (it decrements the count) and attempts to acquire more resources (waits until the negative count becomes zero or positive). This can be avoided by making the process in all cases decrement the semaphore with the full value of the second parameter to P. One possible solution, which needs two wait queues (a.k.a. condition variables) and some auxiliary variables is this:
 P (Semaphore s, unsigned int n)
 {
   if (s->count >= n)
     s->count -= n;
   else
     {
       if (s->first == false)
         wait_on (s->q0);
 
       s->first = true;
       s->needed = n;
       wait_on (s->q1);
       s->count -= n;
       s->first = false
 
       wakeup (s->q0);
     }
 }
 
 V (Semaphore s, unsigned int n)
 {
   s->count += n;
   if (s->first == true)
     {
       if (s->count >= s->needed)
         wakeup (s->q1);
     }
 }
Velco (talk) 22:27, 13 November 2008 (UTC)
thread_title:  Counting semaphore wrong 

message: In the following code snippet:
    P(Semaphore s) // Acquire Resource
    {
      wait until s > 0, then s := s-1;
      /* must be atomic because of race conditions */
    }
Is it the entire function that is atomic or just the statement s := s-1?
--AlanH (talk) 23:56, 2 May 2009 (UTC)
replies: text: I updated this with the idea that the answer to my question is "just the incrementing statement" as that (a) makes sense and (b) is reflected in the "howmany" code.  —Preceding unsigned comment added by AlanH (talk • contribs) 00:00, 3 May 2009 (UTC)
replies: text:  The whole function.  If you made just s := s-1 atomic, someone could set s to 1, then two threads might see that s > 0 and both do the decrement.  If the decrement is atomic the answer would then reliably be -1 (instead of being either 0 or -1) but the operation of the P function would still be wrong.  Paul Koning (talk) 21:37, 16 December 2014 (UTC)
thread_title:  Ambiguity on atomicity of P 

message: I think the examples do a pretty good job of explaining the use of Semaphores, but the use of the operator (colon, equals) := seems to be confusing to me. After digging a little bit online I've found that the := operator is used in Delphi. Perhaps I'm missing something? If this is the case, perhaps it should be explicitly stated that this is in fact an example written in Delphi.  —Preceding unsigned comment added by 216.254.69.105 (talk) 19:06, 11 June 2009 (UTC)
thread_title:  Programming Examples 

message: The code snippets for P and V are inaccurate and imply busy waiting while in fact, semaphores do not busy wait. Nor is the order of events entirely accurate. No mention is wait of queuing waiting threads. Formal definition of P and V is as follows. They are assumed to be atomic.
    void P(Semaphore s) {
        s.count--;
        if (s.count < 0) {
            <place process in s.queue>
            <block this process>
        }
    }
    void V(Semaphore s) {
        s.count++;
        if (s.count <= 0) {
            <remove a process P from s.queue>
            <place process P on ready list>
        }
    }
Actually making these atomic requires hardware support, such as the testset instruction. An example implementation would be
    void P(Semaphore s) {
        while (!testset(s.flag)) <do nothing>;
        s.count--;
        if (s.count < 0) {
            <place process in s.queue>
            <block this process and set flag to 0>
        } else {
            s.flag = 0;
        }
    }
    void V(Semaphore s) {
        while (!testset(s.flag)) <do nothing>;
        s.count++;
        if (s.count <= 0) {
            <remove a process P from s.queue>
            <place process P on ready list>
        }
        s.flag = 0;
    }
s.flag is used to ensure mutual exclusion. testset(x) is atomic and returns true if the x could be set (if x was 0), otherwise it returns false. This does use busy waiting, but since both P and V take very little time that does not pose a real problem.
Source: Operating Systems, by William Stallings  —Preceding unsigned comment added by 193.190.253.160 (talk) 01:02, 18 June 2009 (UTC)
replies: text: Whether you do busy waiting or rescheduling is an implementation optimization detail.  Busy waiting is valid (the result is correct) and in some situations may well be the best answer in practice.  In any case, the description given is a minimal description of the correct behavior, not a detailed program for a particular implementation. Paul Koning (talk) 21:39, 16 December 2014 (UTC)
thread_title:  Accuracy of description of P and V 

message: I didn't understand this part:
"It should be noted that the semaphore count is not necessarily equal to the buffers available in the pool. The checking and waiting twice for the s >= 0 condition in P is needed to guarantee that as multiple processes are added to the semaphore's waiting list they do not disturb each other's request: a process does not change the semaphore's count until it is next in the queue. In real implementations it is done without actually activating up the waiting process for the intermediate step."
where were we "checking and waiting twice for the s >= 0 condition in P"? thanks Bayle Shanks (talk) 23:47, 18 November 2009 (UTC)
thread_title:  Don't understand this part 

message: with Public parking lot (cars waiting in queue for free resource) or Restaurant (people waiting for tables)
Thanks, Zvika
13:50, 13 January 2010 (UTC)
thread_title:  Suggesting to replace public toilet analogy 

message: This is not an especially important problem, as everyone will understand the meaning, but I think we should consider rewriting the phrase
If several diners simultaneously arrive, the maître d will seat them in the order of arrival
I understand that the diners would not literally arrive simultaneously, but it still sounds a bit strange, worded as above.
-
94.192.173.115 (talk) 15:54, 4 March 2010 (UTC)
thread_title:  Rewording of Anecdote 

message: I flagged the following statements as contradictory:
"(A mutex is really a semaphore with two values.)"
"Mutexes are usually more efficient than binary semaphores."
More information needs to be presented, otherwise these statements are confusing.  If a mutex is a semaphore with 2 values (a binary semaphore) then it cannot be more or less efficient than the same.  If interpreting the meaning of "a semaphore with 2 values" as a binary semaphore is incorrect, then that only further supports the need for elaboration.
Tseiff (talk) 18:22, 28 October 2010 (UTC)
thread_title:  Inconsistent statements in Mutex vs. Semaphore need elaboration. 

message: I find it extremely difficult to believe that Dijkstra could be the inventor of this concept, since it would have been an essential part of any complex operating system well prior to 1965, especially in multiprocessing environments. What proof is there that nobody else had ever thought of it previously? Information technology is a domain in which the wheel is regularly and routinely reinvented. Agateller (talk) 20:14, 10 January 2011 (UTC)
replies: text: The oldest publication I can find is by Dijkstra in either 1962 or 1963, the article now cites that one.  As for "any complex operating system well prior to 1965", if you know of any that use this sort of mechanism, please propose a citation.  Have you looked at operating systems that old?  I have some experience with CDC mainframe operating systems whose origin is around 1964; those don't use semaphores or anything even remotely like it.  His famous paper  was a seminal paper in 1968; it was among the first, if not the first, descriptions of an operating system structure in terms of cooperating processes with explicit synchronization.  So yes, I find the evidence compelling, especially in the absence of anything to contradict it. Paul Koning (talk) 21:46, 16 December 2014 (UTC)
thread_title:  "Invented" by Dijkstra? 

message: I have been reading Tanenbaum's "Modern Operating Systems" lately and saw that his solution to this problem uses one more semaphore, as follows:
 produce:
     P(emptyCount)
     P(useQueue)
     putItemIntoQueue(item)
     V(useQueue)
     V(fullCount)
The consumer does the following repeatedly:-
 consume:
     P(fullCount)
     P(useQueue)
     item ← getItemFromQueue()
     V(useQueue)
     V(emptyCount)
The idea is that we need a third semaphore to handle mutual exclusion to the queue, whereas emptyCount and fullCount manage synchronisation issues having to do with the limits of using the queue (not using it when it is full or empty, respectively). I think that this is indeed needed, but wanted to raise the point before making the addition.  —Preceding unsigned comment added by 188.4.182.33 (talk) 21:48, 20 March 2011 (UTC)
replies: text: I came to the talk page looking for this very point: the pointers to the head and tail of the queue are a shared resource as well, which need to be protected from multiple access. --76.126.236.172 (talk) 01:36, 21 March 2011 (UTC)

text: As another note, the language is never specified. I presume that it is C# given the other references to it in the talk page here, but as I do not program in said language (although this page was helpful in terms of qualitative details), I was a little confused with the code examples in the article (although they are not so difficult to understand except for the syntax, which I am unfamiliar with).  Even just a "The following C# example illustrates _____" would suffice. 72.54.101.10 (talk) 17:31, 19 July 2011 (UTC)

text: Agreed, this is a terrible example...the current code in the article is bogus. To anyone who reads this message, there is no need to let the article rot away for over a year. If you see something wrong in a Wikipedia article, please do take the time to at least mark it with a template indicating the problem, for example "this section appears to contradict itself". I'll merge in the corrected version in a little bit... 173.239.78.54 (talk) 04:00, 21 May 2012 (UTC)
thread_title:  Producer/Consumer example 

message: The description for a semaphore is inaccurate and confused with the "mutex" concept. In analogy with Flag Semaphore a Semaphore in programming is a simple mechanism for inter process communication, or signalling. It is not inherently an access control mechanism, although it can be used to implement some access control mechanisms.
In the cited paper by Edsger Dijkstra the concept is introduced in section 3.2 under the heading "The Synchronizing Primitives" and is described as
a) among the common variables special purpose integers, which we shall call "semaphores".</p>
b) among the repertoire of actions, from which the individual processes have to be constructed, two new primitives, which we call the "P-operation" and the "V-operation" respectively. The latter operations always operate upon a semaphore and represent the only way in which the concurrent processes may access the semaphores.
In addition the primitives are described as "indivisible" or atomic.
The concept was developed by Edsger Dijkstra to address a particular type of synchronisation problem. Namely the "Producer - Consumer" problem. Semaphores can be used to implement Mutual Exclusion.
--Dopey68 (talk) 06:31, 25 November 2011 (UTC)
thread_title:  Description Inaccuracy 

message: I find the intro's claim that semaphores are used in parallel processing to seem to (by omission) not include the computers which have a single-threaded CPU and yet allow multi-user processing.  Users may hold a resource for an extended period of time and semaphores are used to block subsequent users from accessing the resource, until the first user process is complete.  This is not parallel processing, the CPU only works on a single task at a time.Wjhonson (talk) 18:16, 6 November 2012 (UTC)
thread_title:  Multi User 

message: According to the article, "a semaphore is a variable or abstract data type that provides a simple but useful abstraction for controlling access, by multiple processes, to a common resource". That is not what a semaphore is. That's a mutex. Semaphores are used for syncronisation between processes. Semaphores and mutexes may be implemented by the operating system in similar ways (using a counter variable), but they are used in different ways. This article blurs the distinction between them. A major article overhaul is needed. --Frederico1234 (talk) 18:23, 2 August 2013 (UTC)
replies: text: A Mutex is a type of semaphore. Specifically a binary one. Carewolf (talk) 22:01, 25 August 2014 (UTC)
thread_title:  Article fails to explain what a semaphore is 

message: I reverted this edit. However I then started looking more closely at the "simple way to understand." I corrected the wait() function, but signal() is still missing something. Since wait() never decrements the counter if it's already negative, the counter will never be less than -1. Suppose there are three waiters; the value will still be -1. So, when signal() is called, it will "increment the value by 1" - now the counter is zero. Since the old value was negative it will release one waiter, but subsequent calls to signal() will not release any. 
I know how this works, but I'm not certain of the best way to phrase it in English. Jeh (talk) 09:42, 5 March 2015 (UTC)
thread_title:  "A simple way to understand" is not complete... I don't think 

message: I already described my complaints with this material in the edit summary for my revert, so it would actually be up to  to open the dialog here if s/he wants to. However... 
 in other words An integer value used for signaling among processes. 
This "sentence" has no subject. And it describes an implementation detail that is, at once, too detailed for the lede and not complete  enough for the body (not just any "integer value" will do). 
 Only three operations may be performed on a semaphore, all of which are atomic: initialize, decrement, and increment. 
This is also too detailed for the lede, and the first claim is not always true. True, this is the list of fundamental operations of a semaphore but others may be implemented. 
 The decrement operation may result in the blocking of a process, and the increment operation may result in the unblocking of a process. 
Nothing requires this particular "polarity". It also invites the question of "may result? When would it, and when would it not?" Too much for the lede. 
 Also known as a counting semaphore   or a   general semaphore.
This "sentence" too has no subject. More seriously, the term "counting semaphore" is already mentioned later in the lede. "General semaphore" is not mentioned anywhere else in the article, therefore should not be in the lede. 
The grammar issues could be easily fixed, of course, but the factual and organizational problems remain. The lede is sufficient as it was. Jeh (talk) 08:54, 3 March 2016 (UTC)
replies: text: Further investigation showed that the material added was a clear COPYVIO. I've removed it. Jeh (talk) 09:30, 5 March 2016 (UTC)
thread_title:  Recent edits to lede by Dipankarpal5050  

message: Prior content in this  duplicated one or more previously published sources. The material was copied from: https://freefundkenotes.files.wordpress.com/2014/02/william-stallings-operating-system.pdf. Copied or closely paraphrased material has been rewritten or removed and must not be restored, unless it is duly released under a compatible license. (For more information, please see "using copyrighted works from others" if you are not the copyright holder of this material, or "donating copyrighted materials" if you are.)
For legal reasons, we cannot accept copyrighted text or images borrowed from other web sites or published material; such additions will be deleted. Contributors may use copyrighted publications as a source of information, and, if allowed under fair use, may copy sentences and phrases, provided they are included in quotation marks and referenced properly. The material may also be rewritten, providing it does not infringe on the copyright of the original or plagiarize from that source. Therefore, such paraphrased portions must provide their source. Please see our guideline on non-free text for how to properly implement limited quotations of copyrighted text. Wikipedia takes copyright violations very seriously, and persistent violators will be blocked from editing. While we appreciate contributions, we must require all contributors to understand and comply with these policies. Thank you.  Jeh (talk) 09:36, 5 March 2016 (UTC)
thread_title:  Copyright problem removed 

message: In the preamble the following line appears:
"A useful way to think of a semaphore as used in the real-world systems is as a record of how many units of a particular resource are available, coupled with operations to adjust that record safely (i.e. to avoid race conditions) as units are required or become free, and, if necessary, wait until a unit of the resource becomes available."
This line is too long and very unclear. If an expert will reword it to make simpler to understand, perhaps by dividing it into segments, it will be very useful.
Thanks!
Wilkn (talk) 18:17, 31 October 2017 (UTC)
thread_title:  Unclear preamble 

message: Regardless of the various expert debates and refinements still possible, this is a good article in my eyes, good job!
Maxorazon (talk) 20:36, 4 February 2022 (UTC)
thread_title: Re-estimated article quality at last

message: IBM from OS/360 on, uses WAIT/POST, named after the two macro instructions, and the Event Control Block to synchronize operations. It is used for I/O and for task synchronization. I am not sure it is exactly the same as described here. If it isn't, then it should have its own article. Otherwise it should be explained here. Gah4 (talk) 23:22, 10 July 2023 (UTC)
thread_title:  WAIT/POST