Win a copy of OCP Java SE 8 Programmer II Exam Study Guide this week in the OCP forum!

sarvesh meens

Ranch Hand
+ Follow
since Mar 31, 2006
sarvesh likes ...
Firefox Browser Java Netbeans IDE
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
3
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by sarvesh meens


Hello Ranchers!!!

Released version 1.0 of blocking map yesterday.
It is completely open & free.
Blocking map is a Map that additionally supports operations that wait for a key to be available when retrieving an element.
Blocking map acts as a synchronizer between producers and consumers in concurrent environment.

You can find the complete API here
Check out the project home as well.
Play around with it and let me know your opinion on the same.

Your comments are highly appreciated.
6 years ago

In the first case,the object used to lock is private & there is no way for other any other thread to change it (assuming, there is no public setter methods provided). Hence, there are no warnings from the IDE.

In the second case, you are locking on local variable. There is no way for any other thread to access the local variable of another thread.Hence, there are no warnings from IDE.

The best/suggested way to lock in the given scenario is this:


Hope, this helps.

Thread-safety of readLine was the first thing on my mind when I came across this post.
Digging in to the source yielded the following snippet from BufferedReader:



readLine in BufferedReader is thread-safe, so are most of the other methods in the class.
But nothing is mentioned in the API doc about thread-safety.
Now the question is, how will developers get to know whether a method/class is thread-safe if it is not documented in API?
Developers will end up locking/unlocking un-necessarily which incurs a significant performance cost.
Can someone shed some light in this issue?

CountDownLatch will get the job done.
Since there are multiple batches of transactions,consider using a CyclicBarrier so that you can reuse it for subsequent transactions.

The easiest/dirtiest solution to the problem is to use join() after starting all threads that are part of a transaction.
In this specific snippet, place join() after the inner for loop.

Hope that helps.

Callable will get the work done.
Since you are using Swing, take are look at SwingWorker as well. It is specifically designed for the kind of problem you are encountering now.

wait(), notify(), notifyall() are used when threads have to wait on a condition.
The strategy suggested by Henry is the best way to gracefully stop a thread.
The following post illustrates Henry's point. Hope, it is fairly clear now.
I executed the same code & got the following (expected) output:

run:
Reader One: .Starting Console Reader .....
Reader Thr: .Starting Console Reader .....
Reader Fou: .Starting Console Reader .....
Reader Two: .Starting Console Reader .....
12
Reader Thr: reads : 12
33
Reader Thr: reads : 33
45
Reader Thr: reads : 45
5
Reader Fou: reads : 5
7
Reader Fou: reads : 7
8
Reader One: reads : 56
a
Reader Two: reads : a
g
Reader Two: reads : g

set up:
Java - jdk1.6.0_18
IDE - Netbeans
OS - Windows XP SP 2

Executing the code multiple times yields the same result.
Am unable to reproduce the output you have listed.

Let me know if you can reproduce it successfully.
If so, let me know your software setup.

Would like to add a few points to Paul's response.
For the snippet posted, taking a look at turnOn() method and checking for thread safety may provide some clues.
When the program hangs or when you see inconsistent behavior,investigating the thread dump may help.
Refer to this link, for ways to generate thread dump.

Hi Nimesh,

Interesting problem.

Let me summarize my understanding of the requirement.

  • There is a booking system
  • HashMap is the core data-structure used
  • I assume room number as key & customer ID as value
  • Rooms may be booked from a number of threads
  • Room booking should happen in a consistent manner in this multi-threaded environment.


  • Can think of three ways to meet this requirement.

    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    Approach I - Simple hashmap

  • Use a simple hash-map
  • synchronize every action on it (i.e read, write, iteration, etc)
  • No two threads will be acting on the map at the same time.
  • When a thread is writing on HashMap, another thread cannot read and vice-versa
    Hence, no inconsistencies


  • Advantages:
  • Consistent behavior
  • Easy to understand solution


  • Dis-Advantages:
  • Only one thread can book at a time - performance bottle neck
  • Need to synchronize each and every action on HashMap - Tedious programing construct, Error-prone


  • ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    Approach II - Synchronized hashmap

  • Use a synchronized hashMap


  • No need to synchronize every action on hashmap since all methods in synchronizedHashMap are implicitly synchronized.
  • Iteration is the only activity for which manual synchronization is required.
  • No two threads will be acting on the map at the same time.
  • When a thread is writing on HashMap, another thread cannot read and vice-versa.
    Hence, no inconsistencies


  • Advantages:
  • Consistent behavior
  • No need for manual synchronization on every action


  • Dis-Advantages:
  • Only one thread can book at a time - performance bottle neck


  • +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    Approach III - ConcurrentHashMap

  • Use ConcurrentHashMap as the core data structure
  • ConcurrentHashMap assures consistent behavior in a concurrent environment & blocking is kept to a minimum
  • When a room has to be booked, use concurrentHashMap.putIfAbsentkey,value).
  • Behavior of putIfAbsent is given below:
    If the specified key is not already associated with a value, associate it with the given value. This is equivalent to


  • except that the action is performed atomically.

  • putIfAbsent returns the old value
    i.e it returns null if there was nothing there earlier
    returns old value if there is already a value
  • Booking logic should be as given below:




  • Advantages:
  • Consistent behavior
  • No performance bottle neck. Rooms can be booked from all threads.
  • No blocking


  • Dis-Advantages:
  • None I could think of


  • +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    Am curious, why do you try to avoid Java's concurrency tools?

    I hope you find this useful.

    We are planning to build an EMS.
    We are looking for EMS frameworks.
    Adventnet is the only framework we could find so far.
    Does anyone know any other EMS framework?

    9 years ago
    Got the BlockingQueue I was looking for @ forums.sun.com.
    Worked a lil on the same.
    The improvised BlockingQueue is available here

    Ulf,thanks a lot for the point on forum etiquette.

    [ August 12, 2008: Message edited by: sarvesh meens ]
    [ August 12, 2008: Message edited by: sarvesh meens ]
    Hello Ranchers,

    Wouldn't it be a good idea to have a BlockingMap similar to BlockingQueue.

    Our application has the following logic:



    Couldn't find any implementation that meets this requirement.
    Obviously,it has to be concurrent as well.
    Queue will not be useful here because,I have to wait for a particular key and not for any available key.

    Do you know any container that meets the above requirments?
    We have to build an enterprise-class web application that will manage more than a 1000 exchanges.
    There will be more than 1000 users.
    The following features will be critical for our application:
    * concurrency
    * access control
    * transaction mgmt
    * persistance
    * scalability
    Since we already have lot of core-java modules which we could use in this application,we chose J2EE platform.

    Now the question is choosing between JSF and GWT.
    Where exactly does JSF score over GWT?
    I've googled for JSF Vs GWT.
    But coudnt find anything that is up to the point.

    To put it the question in simpler terms,it should be stated as:
    Which is better suited to build an enterprise-class application: JSF or GWT?
    And why?
    9 years ago
    JSF
    * Thread should obtain the object's monitor before invoking wait() or notify() on it.
    * Locks,synchronized blocks/methods are the techniques to acquire object monitor. Depending on application requirement,suitable technique should be adopted.
    * wait() should always be matched with a notify(). If you get rid of java.lang.IllegalMonitorStateException in the above example by aquiring the object's(one) monitor,main-thread will wait for-ever.
    * You may find this discussion helpful.
    [ June 05, 2008: Message edited by: sarvesh meens ]
    hello pavel,

    Corrected the following in the web.xml:

    1. The missing <!DOCTYPE ... in web.xml
    2. Changed the parameter value starting with d:\logs\jnlpdownloadservlet.log should be changed to /var/log/jnlpdownloadservlet.log
    3. changed url pattern to /publish/*


    webPad is working fine now !
    Thanks a lot for the prompt response.
    10 years ago