quote:Original post by ServantOfGlaaki
1) Is there anywhere that I can download the entire JavaDoc generated comments of the SDK 1.4, and various APIs?

Yes, they are available from Sun.

quote:2) What does the ''volatile'' keyword mean/do?

Assignments to volatile fields are immediately made visible to other threads. If the field is not volatile, the assignment can be stored in your current thread''s cache and only be made visible to other threads at some later point, possibly after the other thread has tried to access the field and gotten the ''old'' value.

quote:3) How does the ''synchronized'' keyword/synchronized methods work?

It makes sure only one thread can enter a section of code at one time, the other threads will block until the thread that is currently inside the synchronized block leaves it. Synchronized also creates a memory barrier where the cache of the current thread is synchronized with main memory, performing any cached assignments and rereading cached data that has changed in main memory.

quote:Original post by ServantOfGlaaki
In my program, I insantiate 2 ''Sync'' objects, and start them running. Due to the synchronization, if one thread was carrying out the code in the doSomething() method, and the other Thread tried to call the method, am I right in saying that the other Thread would have to wait for the first to finish?

No, not if you instantiate two objects. One thread would only have to wait if you instantiate one object and have both threads access the same object. Synchronization locks work on object basis. If you have several synchronized methods in your object, then any thread that tries to call any method will block if some other thread is executing inside one of those methods (even if they are not calling the same method). However, other threads may concurrently run code in unsynchronized methods in that object, even if one thread is executing inside a synchronized method. Not sure if that makes sense

quote:
Also, could you maybe give me an example of the volatile keyword, as I''m not sure I quite understand you.

Sure, assume that you have a temperature field defined as:

private volatile int temperature = 32;

Now, assume that thread A sets the temperature and thread B reads the temperature. If the field had not been declared volatile, there is really no guarantee that thread B would ever see any temperature value other than 32, even if thread A assigns other values to the field.

Without synchronization or volatile fields, the operation where thread A set the temperature could be cached in thread A''s local memory and only be made visible to the rest of the threads when thread A dies. When thread A runs into a synchronized block or a volatile field it will be forced to either flush all of its cached values (if synchronized is used) or just flush one cached field (if that field is declared volatile).

If the temperature field had not been declared volatile, thread B would also have been allowed to read the temperature once, cache it, and never read it again from ''main memory''. So even if thread A changed the temperature and flushed all of its cached values to ''main memory'', thread B could still be using the old value that it has stored in its cache.

The argument that you pass to a synchronized block lets you specify which object to use as a synchronization lock. When the word synchronized is placed in the method definition, the object on which the method is invoked is automaticly used as the synchronization lock (ie, it is the same as sending this as an argument to a synchronization block that contains all of the code in the method).

Specifying your own synchronization lock is useful when you want to reduce thread contention by splitting locks. For instance, assume that you have synchronized get/set methods for two completely independent fields, A and B, in an object. If you just put the word ''synchronized'' in the method definition for each get/set method, all threads that try to enter one of those methods will use the same object as a synchronization lock, leading to a situation where a thread that wants to access field B will block if another thread is accessing field A, and vice versa.

Using a synchronization block instead of putting synchronized in the method definition lets you specify different lock objects for the methods that access field A and the methods that access field B, so that a thread that accesses field A will not stop other threads from accessing field B, and vice versa.

You could use the variable you want to synchronize access to if it is an object, but you can also specify any other object as the lock. A thread acquires the lock when it enters a synchronized block and releases it when it leaves the block (or if it calls the Object.wait method). No other thread can enter the synchronized block if some other thread has already acquired the lock. That is why it is important that threads whose operation you want to synchronize uses the same lock object.