Confused about volatile regarding the examples in JSDK doc 1.5

Question

In java docs for JSDK-1.5 there is an example for ReentrantReadWriteLock like below:
class CachedData {
   Object data;
   volatile boolean cacheValid;
   ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
   void processCachedData() {
     rwl.readLock().lock();
     if (!cacheValid) {
        // upgrade lock manually
        rwl.readLock().unlock();   // must unlock first to obtain writelock
        rwl.writeLock().lock();
        if (!cacheValid) { // recheck
          data = ...
          cacheValid = true;
        // downgrade lock
        rwl.readLock().lock();  // reacquire read without giving up write lock
        rwl.writeLock().unlock(); // unlock write, still hold read
     use(data);
     rwl.readLock().unlock();
}Why is it neccessary cacheValid to be volatile. If it is neccessary because more than 1 thread can access the variable then in the example for the Condition interface, the variables putptr, takeptr and count why are not volatile too(they are accessed by more threads too)? The ex for the Condition interface in java doc is:
class BoundedBuffer {
   final Lock lock = new ReentrantLock();
   final Condition notFull  = lock.newCondition();
   final Condition notEmpty = lock.newCondition();
   final Object[] items = new Object[100];
   int putptr, takeptr, count;
   public void put(Object x) throws InterruptedException {
     lock.lock();
     try {
       while (count == items.length)
         notFull.await();
       items[putptr] = x;
       if (++putptr == items.length) putptr = 0;
       ++count;
       notEmpty.signal();
     } finally {
       lock.unlock();
   public Object take() throws InterruptedException {
     lock.lock();
     try {
       while (count == 0)
         notEmpty.await();
       Object x = items[takeptr];
       if (++takeptr == items.length) takeptr = 0;
       --count;
       notFull.signal();
       return x;
     } finally {
       lock.unlock();
}

Answer 1

Ok. What's protocol here? Do I post an admission that I probably should not have posted and answer in the first place, since I don't know, or just quietly go away and avoid gunking up the forum with yet another useless reply.
@OP, sorry I didn't understand your original question. I'll watch the thread in the hopes of learning something. If you find out, please post what you learn.
� {�