Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Welcome to Open Discussion

2009-05-24
2013-03-31
  • Welcome to Open Discussion

     
    • Victor Grazi
      Victor Grazi
      2009-06-01

      Goals of this project are to
      Create new animations representing other concurrent components
      Modify existing animations to more closely visualize the represented component

      The project is about the components. The animations should simply be a heuristic learning aid to help users attain a visceral understanding of each component so they can start using them in their projects

      Check out the project, execute the ant build, and launch the self executing jar file in the dist dir.

      Have fun!
      Victor Grazi

       
    • Rob Wilson
      Rob Wilson
      2009-06-06

      I have been meaning to have a look at the new Java 5 threading library, but have been to busy.  It was great news to hear via the JavaPosse forums post that you had created this visual learning aid.

      As I go through each section I'll try to capture my thoughts for your consideration.

      My first thought is that the slides give you a very quick overview before the visualisations are played, but during some visualisations the functions require a little explanation.  For example, the CachedThreadPool is not obvious what the benefit is visually / what it's doing - it would be great for a one sentance explanation on-screen to complement this visualisation (the Java code comment simply says "CachedThreadPool Construction" but I can't see what it's caching and therefore what I'm getting out of it).

      Walking through the slides using page down is good, but seems to skip at least one of the functions in comparison to the drop-down menu.  For example, using page down to navigate to 'sempahore' then again to 'Future', but can't get to 'semaphore (fair)' without using the menu.  Also, explanation of what 'fair' does in comparison would be good.

      Scheduled executors are covered in the slide, but not in the animations?

      Not sure there's enough information for 'condition' - Is it saying that a condition is simply an object that can be used to invoke a signal to enable a single thread to continue or all threads? And that condition object could be passed around the system rather than being a synchronized block of code?  Is there just one 'condition' class that you decide when to indicate that the condition has happened, or can you build up some sort of rule/condition (i.e. 'and' 'or' conditions together)?

      ReadWriteLock - I'm not sure how to use the downgrade to read, it does not seem to do anything (seems to go into 'waiting for downgrade write lock' but stays like that until I unlock.

      It's funnny how some mechanisms timeout with the phrase 'try' (i.e. tryAquire), yet others use the phrase 'offer' for example... they seem to mean the same thing?

      CyclicBarrier, no matter how quickly I click my mouse on await, I can't get more than four threads queued, but I guess it should enable the first four to execute whilst the other new threads wait in the queue?   Although the slide explains clearly that if you launch one await and then two await(timeout) then wait for the timeout to happen, it seems odd (to me) that the await (without timeout) is cancelled too.  I'm just wondering why it has to affect those that didn't care about the timeout.

      Countdownlatch, I'm not sure whether it's obvious from the slides that once the countdown has been reached, all further threads execute immediately.

      AtomicInteger confuses me, if I click compareAndSet three times in a row, all values seem to have the correct assumed value but only one thread executes, I think I could understand that if it was the first thread that was executed, but it seems random which one it picks.

      One massive positive, I have not read anything to do with Java 5 concurrency, yet after running through the animations I feel like I know a fair bit about concurrency in 10 minutes!! A great learning tool - I find visual learning is very powerful, so a big 'thank you' !!!

      Cheers,
      Rob.

       
    • Victor Grazi
      Victor Grazi
      2009-06-07

      it would be great for a one sentence explanation on-screen to complement this visualization
      •    Ok, I will try to expand the explanations on the descriptive slides, and also will add a mouseover to explain what is happening

      Walking through the slides using page down is good, but seems to skip at least one of the functions in comparison to the drop-down menu. For example, using page down to navigate to 'sempahore' then again to 'Future', but can't get to 'semaphore (fair)' without using the menu. Also, explanation of what 'fair' does in comparison would be good.
      •    Each screen use the underlying components to control the animations. Semaphore fair and unfair for some reason have been acting the same in JDK1.6. This seems to be a JDK issue. I removed fair to avoid confusion. I put it back now. (Fair guarantees that waiting threads are released in the order they arrived. Unfair doesn’t)

      Scheduled executors are covered in the slide, but not in the animations?
      •    No reason, just didn’t get to that one

      Not sure there's enough information for 'condition' –
      •    This was hard to visualize, if someone can suggest a better approach please let me know. The way it works is that a lock is created (see the code snippet in the animation) and used to create one or more conditions. Then, threads that wish to be notified when any of those conditions occur will call await on the condition, and will sit there blocking, until another thread calls signal() or signalAll() on that condition. If signal() is called, one thread will be notified. If signalAll() is called, all threads will be notified.

      ReadWriteLock - I'm not sure how to use the downgrade to read, it does not seem to do anything (seems to go into 'waiting for downgrade write lock' but stays like that until I unlock.
      •    Downgrade is not really part of the api. It is mentioned in Sun’s Javadoc for ReadWriteLock. What it does is to convert a read lock to a write lock. The way it does it is that since the lock is reentrant, a write thread that holds the lock can obtain a read lock. Now that it has the read lock, it can release the write lock. To see this in action, create a write lock and then press downgrade. You will see it turn to a read lock. Then create a write lock followed by several read locks. Then press downgrade, and watch the writer become a reader and the waiting readers get access.

      It's funnny how some mechanisms timeout with the phrase 'try' (i.e. tryAquire), yet others use the phrase 'offer' for example... they seem to mean the same thing?
      •    That is just the concurrent API – it takes some getting used to.

      CyclicBarrier, no matter how quickly I click my mouse on await, I can't get more than four threads queued, but I guess it should enable the first four to execute whilst the other new threads wait in the queue?
      •    The visualization is using a hard coded barrier size of 4. It is behaving as expected

      Although the slide explains clearly that if you launch one await and then two await(timeout) then wait for the timeout to happen, it seems odd (to me) that the await (without timeout) is cancelled too.
      •    The barrier is a contract that all threads must come in. If any thread misses, even due to a timeout, then that contract is broken and the barrier throws a BrokenBarrierException on all waiting threads.

      Countdownlatch, I'm not sure whether it's obvious from the slides that once the countdown has been reached, all further threads execute immediately.
      •    I can add some more explanation to the power point “Once the countdown has been completed, all further calls to await will pass through unblocked

      AtomicInteger confuses me, if I click compareAndSet three times in a row, all values seem to have the correct assumed value but only one thread executes, I think I could understand that if it was the first thread that was executed, but it seems random which one it picks.
      •    the first thread that gets in changes the value. The other threads all have the original value, so when they are compared, they are found to be stale and therefore are rejected. This is an example of CAS compare and swap processing that is very common in concurrent processing

      One massive positive, I have not read anything to do with Java 5 concurrency, yet after running through the animations I feel like I know a fair bit about concurrency in 10 minutes!! A great learning tool - I find visual learning is very powerful, so a big 'thank you' !!!
      •    Thanks and enjoy! Concurrency is hard, the concurrent library makes it easier, but it is difficult to learn. These animations should go a long way in helping, but it takes feedback to get it right. Thanks so much for taking the time to comment.
      Regards, Victor