下面是我的分析：
问题：写者在写，则其余写者和读者等待；写者写完，优先释放下一个写者；
读者在读，若无写者等待，则其他读者可读；读者在读，若有写者等待，则其他读者等待。

互斥：写者之间互斥(故设置信号量write(初值为1))，读者和写者之间互斥(read(1))；读者之间不互斥；
记录当前读者个数(readcount(0))和写者个数(writecount(0))，读者对readcount互斥访问(mutex1(1))，写者对writecount互斥访问(mutex2(1))；
为保证在有读者等待的时候，新写者到来也优先释放写者，让等待的读者继续等待，不能将读者和写者阻塞在同一队列上(mutex3(1))。

阻塞分析：当有写者在写时，其余写者阻塞在write上，第一个读者阻塞在read上，其他的读者堵塞在mutex3上。当一个写者写完后，若有写者等待，则唤醒一个写者，否则唤醒第一个读者，由第一个读者唤醒其余读者。
当有读者在读时，一读者R通过P(read)还未V(read)，此时新到来的第一位写者W阻塞在read上，其余写者阻塞在mutex2上；新到来的第一位读者R1阻塞在read上，其余读者阻塞在mutex3上：（1）若正在等待的第一位写者W先于读者R1到来，则他先被读者R释放，接着W会释放其余写者，使原阻塞在mutex2上的写者通过mutex2，重新阻塞在write上，而所有等待的读者仍然阻塞在原来的地方；（2）否则读者R先释放读者R1，R1代替R的位置，原来等待在mutex3上的第一位读者R2被阻塞在read上，但此时R2在read等待队列上必处于写者W之后，成为情况（1）。因此可以看到，在上面的方案中，新写者到来后，最多再放行一位读者。

这里的mutex1好像没什么作用，因为read的初值是1，故而read可以保护readcount而无需mutex1了。

  读
  
  P(mutex)
  readcount --
  if(readcount == 0)
     V(write)
V(mutex)
==============
读者是这样应该可以吧？
}

这样感觉问题不是太大，但是好像没有充分体现写者优先，例如，现在有一写者在写，来了N个读者全部被挂在read上，写者完成后，读者一个一个的释放，在还没全释放完的时候来了个写者，这个写者只能等这N个读者完成后才能写。

int readCnt=0;       //表示当前读者数目，初值为0
int writeCnt=0;      //表示当前写者数目，初值为0
Semaphore mutexRC;   //互斥对readCnt变量的使用，初值为1
Semaphore mutexWC;   //互斥对writeCnt变量的使用，初值为1
Semaphore read;      //互斥对文件的读与写，初值为0
Semaphore write;     //互斥对文件的写与写，初值为1
Semaphore mutexR;    //用于第一个等待的读者释放后续等待的读者，初值为1

任一读者：
void Reader_i() {
    P(mutexR);
    P(mutexWC);
    if(writeCnt>0) {    //检查是否有写者等待
        V(mutexWC);
        P(read);        //写者优先有则等待
    }//end if
    else
        V(mutexWC);
    V(mutexR);
    P(mutexRC);
    readCnt=readCnt+1;
    if(readCnt==1)      //第一个读者开始读
        P(write);       //阻止后来的写者
    V(mutexRC);
    读文件;
    P(mutexRC);
    readCnt=readCnt-1;
    if(readCnt==0)      //最后一个读者读完
        V(write);       //唤醒等待的写者
    V(mutexRC);
}//end Reader

任一写者：
void Writer_i() {
    P(mutexWC);
    writeCnt=writeCnt+1;
    V(mutexWC);
    P(write);
    写文件;
    V(write);
    P(mutexWC);
    writeCnt=writeCnt-1;
    if(writeCnt==0)    //无写者等待或正在写
        V(read);       //才唤醒读者
    V(mutexWC);
}//end Writer

其实，写者优先要求的尽可能优先唤醒写者，主要就是看在有很多读者排在前面怎么让写者跳过去。

一些变形如无饥饿的第一类读写，并发的'"写者"优先，以及三类不同的优先级的读写问题，等等，大家也可以考虑下。

关于把互斥信号看作token想法很好，可以允许互斥锁在不同进程，相同进程 传替，
还有一些需要把同步看作旋转门的集合点问题，这个近三年考得pv题都是这方面，此外
pv题还有一些设计模式值得注意，常见的“记分板”“i do it for ","传替棒 等

“把同步看作旋转门的集合点“，“记分板”“i do it for ","传替棒“，
无饥饿的第一类读写，并发的'"写者"优先，以及三类不同的优先级的读写

谢谢

我说的意思是make no assumptions to process scheduler的时候。当然PV题写起来就不考虑这个了

把同步看成集合点的意思实际上就是并行计算中的barrier。是指多个进程要共同执行到某个语句后才能一起往下走的意思。
记分板应该是说有多个整形变量，用一个mutex保护起来，然后case操作。
i do it for估计楼上是想写i'll do it for you。思想是同步其他进程时，要注意在自己的mutex仍在手上时把刚才同步的信号量引起的整型变量变化一并处理掉，不然就会错误。这个可以到这个地址去下一篇文章http://cs.rit.edu/~kar/papers
传递棒的意思就是在一些问题中如果一个mutex不是总能马上释放的话，可以在一个V操作后就噶然停止。就相当于原来属于自己的那个mutex交给了自己刚V的那个进程。
无饥饿的第一类读写实际上实现起来并发度不会很高，思想是在每个读者写者的第一步都要争夺一个互斥信号量并持有它直到自己能参与文件的竞争。
三类不同优先级的读写建议大家都想想，思想是用两级信号量。不过优先级如果超过3层了，我暂时还没想到怎么解决。可能用局部变量合整体队列结合能解决但是效率注定不高。