- 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
synchronizedkeyword 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
Tuesday, June 05, 2012
Things I Learned at Hacker Bed & Breakfast
Subscribe to:
Post Comments (Atom)
3 comments:
I should point out that Brian Goetz is very interested in Java; he and I were somewhat the exception to the rule.
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.
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().
Post a Comment