前田です。

|># append_featuresでnewの定義を変えてしまえばよいのかな...。
|
|いや. このままでよいでしょう. 基本的に組み込みクラスのサブクラスを作る
|ことは良くないことであるとされていますので. 作る時にはそれなりの覚悟を
|せよってことで(^^;;;

そうですね、あえて深追いはしないことにします(^^;

|あ, あと, モジュールだけでなく当然モニタクラスも用意されるんですよね? 
|
|# モジュールがあればすぐですが.

はい、sync.rbと同じ手法を使わせていただきました。
他の部分もほとんどsync.rbの手法だったりします。

# ところでsync.rbでextend_classとなっていますけど、append_features
# に変わってますよね?

|# 個人的には今あるQueueを無理に置き換える必要はないと思っていますけど
|# も. 

そうですね。
例としてはわかりやすいのですけど効率はあまりよくなさそうですし...。
# 特にSizedQueue#max=は関係ないスレッドも全部起こしてしまいます。

|>実はbroadcastだとpushした順番通りになるとは限らないのですが(^^;
|
|なんかへんですね. Mutex#unlockでは逆のことをいっていたのに(^^;;;

broadcastはキューの先頭からwakeupするのですが、@waitersをclearする
までは他のスレッドに制御が移らないようにしています。

      Thread.critical = true
      tmp = @waiters
      @waiters = []
      Thread.critical = false
      for t in tmp
	t.run
      end

のように変更すれば、runでスケジューリングイベントが起きた時には
まだrunされてないスレッドは寝ているので、runした時点でtにすぐに
制御が移らなくてもたぶん先頭から順にロックを獲得することになると
思うのですが、何となくbroadcastの度に新しく配列を生成するのがも
ったいないような気がして(^^;

-- 
前田 修吾