Recent Changes - Search:
Thanks to OZU Thanks to OZU

Linked In

links

Reviews

Admin

1&1

edit SideBar

Java

Main.Java History

Hide minor edits - Show changes to markup

March 25, 2010, at 12:40 PM by 195.244.199.238 -
Changed lines 9-20 from:
  1. Immutable objects are automatically thread-safe, and objects that are

not shared across threads do not need to be thread-safe. Therefore share as little as possible and favor immutability wherever possible.

  1. When objects really must be shared and mutable, guard all accesses

(both read and write) to shared fields with a lock on the same object, or make appropriate use of volatile variables.

  1. Avoid acquiring new locks when holding an existing lock. As a direct

consequence of this rule, we must avoid holding any locks when calling unknown or “foreign” code that might attempt to acquire a lock. This includes calls to services or to OSGi? APIs?, many of which can result in callbacks to other bundles that execute in our thread.

to:
  1. Immutable objects are automatically thread-safe, and objects that are not shared across threads do not need to be thread-safe. Therefore share as little as possible and favor immutability wherever possible.
  2. When objects really must be shared and mutable, guard all accesses (both read and write) to shared fields with a lock on the same object, or make appropriate use of volatile variables.
  3. Avoid acquiring new locks when holding an existing lock. As a direct consequence of this rule, we must avoid holding any locks when calling unknown or “foreign” code that might attempt to acquire a lock. This includes calls to services or to OSGi? APIs?, many of which can result in callbacks to other bundles that execute in our thread.
March 25, 2010, at 12:38 PM by 195.244.199.238 -
Added lines 8-20:

Threadsafe tips:

  1. Immutable objects are automatically thread-safe, and objects that are

not shared across threads do not need to be thread-safe. Therefore share as little as possible and favor immutability wherever possible.

  1. When objects really must be shared and mutable, guard all accesses

(both read and write) to shared fields with a lock on the same object, or make appropriate use of volatile variables.

  1. Avoid acquiring new locks when holding an existing lock. As a direct

consequence of this rule, we must avoid holding any locks when calling unknown or “foreign” code that might attempt to acquire a lock. This includes calls to services or to OSGi? APIs?, many of which can result in callbacks to other bundles that execute in our thread.

Edit - History - Print - Recent Changes - Search
Page last modified on March 25, 2010, at 12:40 PM