GLib关于为什么不写GSemphore

最近，程序中用到线程同步，便查些线程同步的方面的资料。但是，GLib中GMutex,GCond,GStaticRWLock都有了，为什么没有Semaphore哪？偶然搜到了一个邮件列表的回复，得到了答案。大学里，操作系统对其可是重点讲的，可是这里却认为它不好，实践和理论还是有距离的。现把原文和翻译放着，自己留作记录。

Re: Glib Semaphores

---

• From: Kaz Kylheku
• To: gtk-devel-list redhat com
• cc: kenelson sequoia ece ucdavis edu
• Subject: Re: Glib Semaphores
• Date: Tue, 16 Nov 1999 15:04:39 -0800 (PST)

---

On Tue, 16 Nov 1999, Karl Nelson wrote:

> Date: Tue, 16 Nov 1999 14:11:05 -0800
> From: Karl Nelson 
> Reply-To: [e-mail]
> To: [e-mail]
> Cc: [e-mail]
> Subject: Glib Semaphores
> Resent-Date: 16 Nov 1999 22:11:10 -0000
> Resent-From: [e-mail]
> Resent-cc: recipient list not shown: ;
> 
> 
> Since glib already provides Mutex and Conditional_Signals, it would
> seem like a good idea to provide a common usage of those in the
> form of Semaphores.  Many threading codes in text books are commonly
> expressed in terms of semaphores as there are conceptually simple
> to do things like lock step producer/consumer, flow combining and
> one pass.  

Semaphores are a poor synchronization primitive from a software engineering
standpoint, because it's harder to verify code which uses them to be free of
deadlocks and race than equivalent code that uses condition variables.  I
believe that semaphores do not provide added utility over conditions and
mutexes.

Certain kinds of problems may be expressed more succinctly using sempahores;
typically problems in which the semaphore's internal counter is exploited
in some way to represent some quantity in the problem space. Among such
problems are resource counting and producer-consumer queues.

A possible advantage of semaphores is that because the shared data they protect
is a simple counter, atomic operations may be exploited to perform the
increment and decrement operations. For that, semaphores have to be implemented
specially, rather than in terms of other primitives such as mutexes and
conditions.  This advantage disappears when the semaphores are used in
conjunction with data that must be separately protected anyway (such as
consumer/producer queue), for then the counter might as well be made part of
the queue structure and protected by the queue's mutex, e.g.

	/* wait for item to become available */

	mutex.lock();

	while (count == 0)
	    item_avail_cond.wait(monitor);

	count--;
	/* remove item */
	mutex.unlock();
	space_avail_cond.signal();

If a semaphore is used instead, a mutex is still needed to protect the
queue. 

	item_avail_sem.wait();
	mutex.lock();
	/* remove item */
	mutex.unlock();
	space_avail_sem.signal();

The succint notation comes from the semaphore's internal management of the
queue counter.  Note that the counter is not kept coherent with the queue state
of the queue structure at all times, because the states of the semaphores
change outside of the region protected by the mutex. This means that the
semaphore which represents the number of items doesn't always have a value that
accurately reflects the number of things actually in the queue.  And also note
how there are really two redundant counters: one semaphore measuring available
items, and one counting the remaining space. The invariant that space + items
== max_len is not satisfied at all times! To prove that the queue is not
misused, for example by trying to remove an item from the empty queue, one has
to prove that the semaphores have reasonable values at all times.  In a trivial
example, this doesn't pose a problem, but in large, complex multithreaded
software, this kind of uncertainty can cause real headaches.


自己翻的，质量差了点，但是自己还是理解了。

在软件工程的角度，信号量是一个坏的元语。这是因为它比使用条件变量去验证代码，释放死锁和竞争。我相信信号量不能提供比条件变量和互斥锁更多功能。
某些特定的问题用信号量描述更简洁一些。经典的问题是信号量内部的计数器在某种方式上用来代表一些数量在问题空间中。在这些问题中，经典的是资源计数和生产者-消费者队列问题。
对于信号量来说，一个可能的优势是，由于信号量保护的共享数据是一个简单的计数。增加和减少计数的操作被实现成原子的操作。为了计数原子的操作，信号量的实现非常特殊，不像其他的
互斥量和条件变量的元语。当信号量和必须单独保护处理的数据联合使用时，信号量的优势就没了，比如生产者/消费者队列。因为这时，计数器可能被放入到队列的数据结构中，并由队列的>互斥信号量保护。例如：
        /* wait for item to become available */

        mutex.lock();

        while (count == 0)
            item_avail_cond.wait(monitor);

        count--;
        /* remove item */
        mutex.unlock();
        space_avail_cond.signal();

如果用信号量代替，还得需要一个互斥信号量去保护队列。
        item_avail_sem.wait();
        mutex.lock();
        /* remove item */
        mutex.unlock();
        space_avail_sem.signal();
上面这段代码显得简洁，它是由信号量内部队列计数的管理而得。注意这个计数器不总是合理的代表队列的状态，因为信号量状态的改变是由外部的互斥量保护的。这就意味着，信号量所代表
的项目的数目不能总是是准确的反映队列中事物的准确数字。并且，它要有两个信号量，一个代表可用项的数目，另一个代表未用项的数目。未用的空间+使用的项不总是等于max_len。为了证
明队列没有被乱用，比如试着从一个空队列中移除一个项，则其中一个信号量必须能证明总是有可用的值，代表未用项的信号量有合理的数值。一个微不足道的例子中，它不能说明问题。但是
，更复杂的问题，复杂的多线程的程序，这种不确定行着实让人头疼。