Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!

Tuesday, June 05, 2012

Things I Learned at Hacker Bed & Breakfast

  • You can spend any amount of money on Scotch, and it keeps getting better
  • A Java instance field that is assigned exactly once via lazy initialization does not have to be synchronized or volatile (as long as you can accept race conditions across threads to assign to the field); this is from Rich Hickey
  • Scotch + Random Internet Images + Speakers == Fun; giving off the cuff talks on silly subjects, with random internet images as your "slides"
  • No one's that interested in Java anymore (at least, not at Hacker B&B)
  • Only ride a zip line backwards if you are prepared to accept the consequences
  • The linkage between honey and fried chicken has not yet penetrated into Research Triangle, despite my best efforts
  • The cost of using the synchronized keyword can go asymptotic with enough threads and contention, making ReentrantReadWriteLock much cheaper in comparison
  • Stu Halloway's house appears to have been designed by the same team that designed the Tardis, and is also bigger on the inside than the outside
  • It is much more efficient to just hand Brian Goetz the $50 buy in, rather than go through the motions of playing poker with him

3 comments:

Unknown said...

I should point out that Brian Goetz is very interested in Java; he and I were somewhat the exception to the rule.

Unknown said...

Hi Howard, could you give more detail about the Hickey quote? I posted a question about it on SO (http://stackoverflow.com/questions/11051863/lazy-initialization-without-synchronization-or-volatile-keyword) but so far the most convincing arguments are that the quote is just wrong.

Unknown said...

Basically, it comes down to this: assignment to a field is atomic so if the value you are assigning is cheap to create and you can live with the occasional duplicate work creating it (and the possibility that different threads may see different objects in the field for a short window) then you are ok.

A lot of the lazy initialization I do doesn't fit that mode: possibly there are multiple fields to be updated, or the cost of creation is high, or I need to ensure that all threads see the exact same value for the field.

Rich immediately brought up examples from the JDK, such as String.hashCode().