Caving Boots

April 3, 2009

The “Wellies” (Wellington boots) in the Facebook “Caving Gear” application inspired some brief conversations on good caving boots:

Some Wellington boots come with felt on the tread — which I’m told is good for traction on slippery rocks while fishing.

Some caving groups, such as the Chouteau Grotto, are known for using shoes with football cleats in very muddy caves like the Devil’s Icebox. And it occurs to me that this might be useful in Carol Cave as well — as long as the boots tie firmly enough to the foot as to not get pulled off when pulling feet out of mud! ;->

Last night at the Banff film festival, the “Canyoneer 2” shoe, at five-ten was recommended. (See “Footwear -> Water” on their flash site.) Looks like it would hold onto the foot well, and keep most mud and sand out of the shoe. But the tread doesn’t look very ambitious. Maybe I should try these for my next pair of caving boots.


(A visitor was looking for OTB Footwear Sar Water Boots, so I thought I’d mention them.)


Bottom line: I have to recommend the Norcross Shrimp Boots, recommended by John Hargreaves.
(See comments.)

Advertisements

Start date at Monsanto

March 24, 2009

I have a start date to serve our customer, the research side of Monsanto, working through Comsys and Advantage consulting:  Monday, April 6th.

 

Monsanto is one of the best customers I’ve had the pleasure of working with, and I look forward to the opportunity to serve with them again.


Minor Fresh Concrete Crisis

March 17, 2009

Local color: They just poured concrete to repair the road outside my house this morning. Within seconds of them leaving, the neighbor’s youngest fell in it. I pulled him out by his feet; and while his parents washed him off, I caught the workers on the next street so they could fix the concrete. They said that things like this happen all the time. ;->

This one could be harder to explain to your supervisor, however:
Police car in fresh concrete (from this page)


The Pure Danger of Unfair Read-Write Locks

March 13, 2009

Attending the local No Fluff Just Stuff conference in Saint Louis on Friday, I raised a question during Alex Miller’s talk on Java Concurrency Idioms regarding the documented behavior of the ReentrantReadWriteLock of “A nonfair lock that is continously contended may indefinitely postpone one or more reader or writer threads, […]

So I commented on Alex’s “Writing while reads pile up” blog entry, saying:

My question on Friday was regarding the potential for a sequential set of overlapping readers locking out a waiting writer forever. It seems that this could happen, as the JavaDoc explicitly says, “A nonfair lock that is continously contended may indefinitely postpone one or more reader or writer threads”.
The scenario I had in mind would work like this:
1. Reader 1 gets a read lock.
2. The writer requests a write lock, and is blocked.
3. Reader 2 requests a read lock — and let’s say they get it.
4. Reader 1 releases their read lock.
5. Reader 3 requests a read lock — and let’s say they get it.
6. Reader 2 releases their read lock.
As long as steps 5 and 6 are repeated as shown above, the writer would be delayed indefinately.
However, in writing tests for this, I’m finding that the ‘java.util.concurrent.locks.ReentrantReadWriteLock’ class has the (apparently undocumented) behavior that it stops granting read locks when a write lock is requested. So it appears that even in non-fair mode, readers will NOT block writers indefinitely. (…as long as every lock holder releases their lock within a reasonable period of time!)
What I find is that in step 3 above, Reader 2 is delayed until the writer gets, uses and releases the write lock. So the write does NOT get indefinitely postponed in this scenario.

Not wanting to keep secrets, I am posting here the code I’m using to come to this conclusion:

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.locks.ReentrantReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock.ReadLock;
import java.util.concurrent.locks.ReentrantReadWriteLock.WriteLock;
import org.junit.Test;

public class LockTest {
private List readThreads = new ArrayList();

@Test
public void runTest() throws InterruptedException {
final boolean isFair = false;
final ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock(isFair);
final ReadLock readLock = readWriteLock.readLock();
final WriteLock writeLock = readWriteLock.writeLock();

System.out.println(“===================================”);
System.out.println(“–> Start working read threads.”);
final int readersPerBatch = 5;
for (int idx = 0; idx Start blocking read threads.”);
for (int idx = 0; idx >> WRITE LOGIC HERE <<<“);
writeLock.unlock();
System.out.println(“Main: Released write lock.”);
System.out.println(“===================================”);

for (final Thread thread : readThreads) {
thread.join();
}
System.out.println(“===================================”);
System.out.println(“Done.”);
}

private void startReadLockThread(final ReadLock readLock, final int thisReaderNumber) {
final Thread thread = new Thread(new Runnable() {
@Override
public void run() {
final String messagePrefix = “Reader ” + thisReaderNumber + “: “;
System.out.println(messagePrefix + “Started.”);
sleepSeconds(1);
System.out.println(messagePrefix + “Asking for read lock.”);
readLock.lock();
try {
System.out.println(messagePrefix + “Has read lock.”);
System.out.println(messagePrefix + “‘Working’ with read lock.”);
sleepSeconds(6);
} finally {
System.out.println(messagePrefix + “Releasing read lock.”);
readLock.unlock();
}
}
});
readThreads.add(thread);
thread.start();
}

private static void sleepSeconds(double seconds) {
try {
final long milliseconds = Math.round(seconds * 1000);
Thread.sleep(milliseconds);
} catch (InterruptedException ex) {
ex.printStackTrace();
}
}
}

Sample Output:

===================================
--> Start working read threads.
Reader 1: Started.
Reader 3: Started.
Reader 2: Started.
Main: Sleeping.
Reader 5: Started.
Reader 4: Started.
Reader 5: Asking for read lock.
Reader 5: Has read lock.
Reader 5: 'Working' with read lock.
Reader 3: Asking for read lock.
Reader 3: Has read lock.
Reader 3: 'Working' with read lock.
Reader 1: Asking for read lock.
Reader 1: Has read lock.
Reader 1: 'Working' with read lock.
Reader 4: Asking for read lock.
Reader 4: Has read lock.
Reader 4: 'Working' with read lock.
Reader 2: Asking for read lock.
Reader 2: Has read lock.
Reader 2: 'Working' with read lock.
===================================
--> Start blocking read threads.
Reader 6: Started.
Reader 8: Started.
Reader 7: Started.
Reader 9: Started.
Main: Attempting to acquire write lock.
Reader 10: Started.
Reader 8: Asking for read lock.
Reader 10: Asking for read lock.
Reader 9: Asking for read lock.
Reader 7: Asking for read lock.
Reader 6: Asking for read lock.
Reader 2: Releasing read lock.
Reader 4: Releasing read lock.
Reader 1: Releasing read lock.
Reader 3: Releasing read lock.
Reader 5: Releasing read lock.
===================================
Main: Has write lock.
Main: >>> WRITE LOGIC HERE <<<
Main: Released write lock.
===================================
Reader 8: Has read lock.
Reader 8: 'Working' with read lock.
Reader 10: Has read lock.
Reader 10: 'Working' with read lock.
Reader 6: Has read lock.
Reader 6: 'Working' with read lock.
Reader 7: Has read lock.
Reader 7: 'Working' with read lock.
Reader 9: Has read lock.
Reader 9: 'Working' with read lock.
Reader 8: Releasing read lock.
Reader 6: Releasing read lock.
Reader 10: Releasing read lock.
Reader 7: Releasing read lock.
Reader 9: Releasing read lock.
===================================
Done.

Observe that the Main thread starts up five Reader threads, and waits for them to acquire read locks and start “working.” Main then fires up five more read threads and requests a write lock before the new threads request their read locks. Notice that the five new Reader threads WAIT until the first five threads finish, and the main thread acquires, uses and releases the write lock. And then the five Reader threads that have been waiting all get their locks, do their “work” and finish.

This is much better behavior than I had expected.


Laid off, looking for work.

February 26, 2009

[ Note:  The following status replaced with 2009-03-24: Start Date at Monsanto. ]

 

As of this morning, I found myself a participant in the second round of layoffs at my (now former) employer, Asynchrony Solutions.  They’ve been a great place to work — the people, the work environment, the opportunities to improve myself and to help our customers solve business problems.  But the current economic environment has been very hard on Asynchrony:  Loss of projects and delayed sales have cut income to the point where the expenses of the company, primarily employee salaries, simply had to be cut.

 

So, as of this morning, I am looking for work.

 

I have substantial experience as a consultant and contractor — leading, coaching, and contributing to software development projects in a variety of technologies in both Java and Microsoft environments.  (…including .NET, C#, VB, C++, COM, etc.)

 

I currently live in the Saint Louis, Missouri metropolitan area, and I am willing to relocate to just about any reasonable location.  (I have a preference for the West coast, or possibly Texas, should there be interesting opportunities available.)

 

For the short term, I have a job search to start.  And blogging is not my primary strategy for finding a new job.  ;->

 

Thank you for the interest!

     – jeff


Why Matthias Ernst’s “Chaining: A Modest Language Proposal” for Java would be nice to have

February 14, 2009

OK, shouting at my MP3 player hasn’t been doing me any good; it’s just helping other drivers recognize how passionate I am. ;-> So I’ll try writing about it instead:

After listening to recent Java Posse podcast episodes, I’ve been working my way back to earlier episodes, and I keep tripping over discussions (as in Episide #151) of Matthias Ernst’s “Chaining: A Modest Language Proposal” — which would make the compiler enable a method chaining / “fluid interface” convention on methods returning the void type.

Like the Java Posse members, I’m also somewhat bothered by the idea of reinterpreting void return types, but I think it will be helpful to consider this example of code that would be fixed by his proposal:

Consider these two classes:
public class Base {
  public Base setBaseStuff() { /* ... */ return this; }
}
public class Sub extends Base {
  public Sub setSubStuff() { /* ... */ return this; }
}

This code works:
  new Sub().setSubStuff().setBaseStuff();
This code doesn’t compile:
  new Sub().setBaseStuff().setSubStuff();

The problem is that when you’re using method chaining on classes that extend other classes and which add methods…  You MUST call subclass methods before calling superclass methods.  Otherwise it won’t compile.

With the “Chained Invocations” proposal, if the methods returned void, both method calling orders would compile and work fine.

This happens because the compiler knows more about the type of the callee than the method declaration: When the compiler assumes that void methods return ‘this’, it knows the specific subclass type of ‘this’ — while the method declarations don’t.

In essence…
  new Sub().setBaseStuff().setSubStuff();
becomes
  Sub s = new Sub();
  s.setBaseStuff();
  s.setSubStuff();

This may not seem like much. But what happens when you have a significant number of methods, and possibly several inheritance levels?

Consider these classes:

  public class A {
    public A a1() { /* ... */ return this; }
    public A a2() { /* ... */ return this; }
    public A a3() { /* ... */ return this; }
  }
  public class B extends A {
    public B b1() { /* ... */ return this; }
    public B b2() { /* ... */ return this; }
    public B b3() { /* ... */ return this; }
  }
  public class C extends B {
    public C c1() { /* ... */ return this; }
    public C c2() { /* ... */ return this; }
    public C c3() { /* ... */ return this; }
  }

And this expression:
  new C().c1().c2().c3().b1().b2().b3().a1().a2().a3();

DON’T GET ANY METHOD CALLS OUT OF ORDER!
Like this:
  new C().c1().c2().a2().c3().b1().b2().b3().a1().a3();
OR IT DOESN’T COMPILE!!!

So are we on the same page now, as to why this change might be nice to have?


New Google Mapplet release: GPS Location

February 12, 2009

I just released a new Google Mapplet, I’m calling “GPS Location“. [Click on the “GPS Location” link to add it to your Google maps as a “My Maps” tool.]

I was inspired to write this by using Thomas Duebendorfer’s “Position Finder” Google Mapplet: I’ve been using it for several months, but have been frustrated with its limitations, and how much I have to “futz” with its output to get suitable results. So I wrote my own.

What makes my GPS Location Mapplet better than Position Finder is…

  • I round the latitude and longitude values to a reasonable number of decimal places, given the current zoom level. It was just annoying the heck out of me when Position Finder gave me coordinates that were 8 to 10 orders of magnitude more precise than the maximum resolution one can legally get in public satellite maps. I was always rounding the results by hand.
  • GPS Location supports multiple points on the map simultaneously. And you can move them.

I’m still trying to figure out how to jsUnit test my little GPS Location Mapplet — both integration tests within Google Maps, and Test Driven Development (TDD) code writing with mocks for the Google Map APIs. But those are stories to be implemented another day.