»

[Kyle]

Stressed out about the final exam tomorrow. Needing quick help with Threads (subtopics: intrinsic lock, explicit lock, Executors class) in Java Language.

Your two cents will make my day brighter.

[chuckd]

How did your exam go kyle ??

[Kyle]

Originally Posted by chuckd How did your exam go kyle ??

I ended up doing okay on it.

[chuckd]

Originally Posted by Kyle Stressed out about the final exam tomorrow. Needing quick help with Threads (subtopics: intrinsic lock, explicit lock, Executors class) in Java Language. Your two cents will make my day brighter.

One of the concerns with an upgrade to Java 5 was the semantics of Thread
scheduling. In java 1.4 the thread scheduling was largely left to the OS (see
Bug ID: 4985566 Equal priority threads not timslicing properly in Linux). In java 5 the JVM
defaults to an Non-fair scheduling algorithm, where a thread can jump to the
front of the queue if a lock becomes available. Generally this approach with
be faster on enterprise systems as it means that short running threads can grab
a lock instead of waiting for long running threads to finish. In certain
circumstances, it can lead to starved threads, particularly when there are long
running threads all contending for the same lock. This is often a sign of
poorly designed synchronization. It is important to note that the JVM spec
does not promise any particular order of thread scheduling, so if we plan to
support multiple JVM versions, we need to make sure not to assume a thread
order with default synchronization. If starvation problems do occur (I do not
anticipate this), we have two options: 1) reduce the amount of synchronization,
if appropriate, or 2) replace the synchronization with the Lock constructs from
java.util.concurrent and it's backport. These locks allow us to specify Fair
scheduling. However, I doubt this will be an issue. if it is, though it's a
bug that needs to be fixed properly, instead of assuming a version.

Secondly, Java 5 presents a significant performance boost using Locks over
synchronized{} blocks. This advantage is not present in Java 6. Locks are
slightly more difficult to use because the developer is required to unlock in a
finally block. Failing to do so can lead to myriad problems down the road.
Generally the explicit locks are recommended when you need a special feature
not provided by intrinsic locks (timeouts, cancellations, non-block locks). In
the case of core, since we we not be upgrading to java 6 for the forseeable
future, we we find the places of most contention, likely the request handling
code and the ResourceHome code and replace the intrinsic locks with explicit
locks. This way we can gain the performance advantages without upending the
entire codebase





Shameless copy/paste

[Kyle]

Nice, thanks.

Reminds me of one of the exam questions: advantage of explicit lock over intrinsic lock! XD

[Superfly]

Stress sucks doesnt it buddy? God im glad I am done with finals till next fall lol

[pearlpam]

Yes, it is really a very good suggestion to the entire student or we can say that a good remainder for every student to remind me for the exam questions: advantage of open security device.