Re: What you get is what you want

Quartz wrote:
>>My proposal is that *only* the queue 
>>implementation (and maybe just a queue decorator) have a dependency to 
>>SandstormThread or SandstormThreadPool.
> 
> 
> Which is already too much.
> I should be able to plug in an alternate TM (that means threads too)
> without breaking the behavior.

Yes, we need to be able to change the TM and Thread implementation 
without impacting other classes.  My proposal make also this possible. 
We could define an abstract class which all others threads specifics to 
TM could extends:

public abstract SandstormThread extends Thread {
   volatile boolean blocked;
   public void setBlocked(boolean value) {
     blocked = value;
   }
   public boolean isBlocked() {
     return boolean;
   }
}

And now we can create a queue decorator like this:

public class BlockingQueueDecorator implements BlockingQueueIF {
   QueueIF q;

   public void blocking_enqueue(QueueElement x) {
     // first, try to enqueue without blocking
     boolean success = q.enqueue_lossy(x);

     if (!success) {
       SandstormThread t = (SandstormThread) Thread.currentThread();
       t.setBlocked(true);
       try {
         q.blocking_enqueue(x);
       } finally {
         t.setBlocked(false);
       }
     }
   }
   ...
}

I think that it's the simplest way to achieve our goal.

Jean




-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8