Skip to main content

Home/ ProgrammingPages/ Group items tagged HTML

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Navneet Kumar

Seven steps to remarkable customer service - Joel on Software - 0 views

www.joelonsoftware.com/...customerservice.html

article customer_service joel sales

shared by Navneet Kumar on 12 Mar 07 - Cached
  • Navneet Kumar on 12 Mar 07
     
    seven things for a remarkable customer service
Navneet Kumar

Synchronization and the Java Memory Model - 3 views

gee.cs.oswego.edu/jmm.html

Java JVM Synchronization Concurrency MemoryModel Threads

shared by Navneet Kumar on 08 Apr 11 - Cached
    • Navneet Kumar
      Navneet Kumar on 08 Apr 11
       
      Assignment to a long, double, float variables are not Atomic.
  • as-if-serial property of these manipulations shields sequential programmers from needing to know if or how they take place. Programmers who never create their own threads are almost never impacted by these issues
  • All changes made in one synchronized method or block are atomic and visible with respect to other synchronized methods and blocks employing the same lock, and processing of synchronized methods or blocks within any given thread is in program-specified order. Even though processing of statements within blocks may be out of order, this cannot matter to other threads employing synchronization.
  • ...6 more annotations...
  • atomicity alone does not guarantee that you will get the value most recently written by any thread. For this reason, atomicity guarantees per se normally have little impact on concurrent program design
  • Thread.start has the same memory effects as a lock release by the thread calling start, followed by a lock acquire by the started thread
  • releasing a lock forces a flush of all writes from working memory employed by the thread, and acquiring a lock forces a (re)load of the values of accessible fields. While lock actions provide exclusion only for the operations performed within a synchronized method or block, these memory effects are defined to cover all fields used by the thread performing the action.
  • If a field is declared as volatile, any value written to it is flushed and made visible by the writer thread before the writer thread performs any further memory operation (i.e., for the purposes at hand it is flushed immediately). Reader threads must reload the values of volatile fields upon each access.
  • you will obtain either its initial value or some value that was written by some thread, but not some jumble of bits resulting from two or more threads both trying to write values at the same time
  • As a thread terminates, all written variables are flushed to main memory.
« First ‹ Previous 41 - 45 of 45
Showing 20▼ items per page