poorna k

Greenhorn
+ Follow
since Oct 16, 2000
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
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by poorna k

Congrats! that is a really superb score

Originally posted by poorna k:
I have a few doubts about this example you have given.
As per my understanding , wait() and notify() methods are available to all objects,and is meaningfully used when you are synchronizing an object.
The wait() method defined for the object being synchronized will act on the current thread,and cause it to release its lock on the object.
The notify() method on the other hand,causes the threads in the waiting pool to get notified about the imminent release of the object lock held by the current thread.
Rob, as per the above understanding
I feel that the corral is similar to a waiting pool for the threads(cows here ) to get a lock of the object(the gate to exit the corral).
When a cow is currently in the process of exiting the gate(that is it holds lock on the object),if it executes the wait() method defined there,the current thread /cow releases the lock and comes back into the corral,giving up the gate.
If on the other hand a cow /thread is on the way out,and is going to release the lock (no longer using the gate ),the notify() or notifyAll() method is called on the cows still within the corral,and the thread scheduler / ranch hand selects a cow to go out the gate.So this lucky cow gets the key to the gate.
Is this correct??
thanks
poorna


as per the API the write(int b) method of InputStream class
"Writes the specified byte to this output stream. The general contract for write is that one byte is written to the output stream. The byte to be written is the eight low-order bits of the argument b. The 24 high-order bits of b are ignored. "
The subclasses of InputStream /OutputStream write to the stream as bytes.
A character is stored as 16 bits in Unicode character set.All
the characters in the ASCII character set are represented as a subset in the Unicode character set convention by ignoring the first 8 significant bits in the Unicode representation.
In the ascii convention,characters can be represented as integers also,
e.g the character 'A' can be represented as 065 in decimal
Since automatic type promotion is allowed in java from char to int,your write() method would convert the char argument to int,and as per the above quote, write only the 8 low-order bits to the stream
coming back to your qn when you invoke
write('t'),
't' can be represented as 116 in decimal.so type promotion occurs from char to int.116 can be represented within the lower order 8 bits,and the 8 high
-order bits are zeros.So you will not
be losing any information from the high-order bits.
If you use other characters from the unicode character set(e.g characters from other languages such as spanish)
you would need to use the subclasses of Reader / Writer ,so that all the 16 bits can be output to the stream
I hope this is clear.
[This message has been edited by poorna k (edited October 18, 2000).]
[This message has been edited by poorna k (edited October 18, 2000).]
I dont know what the exact question is,but it depends on whether you are using a byte stream or character oriented stream.
If you use one of the byte streams classes, the output is written as bytes and the write() method takes a int as argument for byte streams.
so if "test" were written to a file using a bytestream class,4 bytes would be needed
if you use public static keyword for displayList() method,you are acquiring a class level lock.So the first thread to acquire the lock on the class retains the lock until it finishes execution.note that there is no wait() call within the synchronized method.so the thread makes no attempt to give up the lock even tho' it sleeps.
in the other case,when public keyword is used before displayList() method,the 2 threads are started on different objects,and are free to execute the synchronized method on the respective object that they have acquired a lock on.
am i right?
I read in one of the faqs that the below stmt is false:
The JVM runs till the main method exits, even if there are other user threads running.
isnt it true that the program terminates when the main thread dies even tho' other user threads may be executing?