Salish Tankard

+ Follow
since Oct 08, 2002
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Salish Tankard

Thanks for the information.
So, they do check against your essay answers.... After so many changes in the design process, it is easily to forget what you actually did. Anyways, you passed. It is the most important thing.....
21 years ago
May I please know when did you submit your assignment and when did you take the written exam? I am still waiting for the result....
21 years ago
I don't think "valid" makes too much sense to emploers, if the technology itself does not have fundamental changes. Say, they deprecate several methods (maybe just name changes), or they add several new classes or packages, would that really erase all the knowlege we have so far?
Any thought?
Hi, I am planning to use SortedSet to store my locked record number, however, I am not sure if it is threadsafe. I read the java doc 1.4, and here is what it said. Am I understanding it correctly that I have two choice:
1. explicitly synchronize my SortedSet object
2. if not, at the creation time, I can wrap the object by using Collections.synchronizedSet method, and the object will be thread safe?
Please help me to clarify this..... thanks in advance...
Note that this implementation is not synchronized. If multiple threads access a set concurrently, and at least one of the threads modifies the set, it must be synchronized externally. This is typically accomplished by synchronizing on some object that naturally encapsulates the set. If no such object exists, the set should be "wrapped" using the Collections.synchronizedSet method. This is best done at creation time, to prevent accidental unsynchronized access to the set:
SortedSet s = Collections.synchronizedSortedSet(new TreeSet(...));

[ November 07, 2002: Message edited by: Salish Tankard ]

Some thoughts:
The code in you locking code isn't synchronized on anything, so it's not atomic(even if it's a single line of code). Say both clients A and B want to lock record #2. Client A checks to see if record @2 is locked. It currently isn't, so A tries to lock record # 2. But A get switched out(because it's thread got switched out). Now client B could check to see if record #2 is locked: it isn't, because A's not done. So B actually succeed in locking record #2. B finishes, and A wakes up again Now, because A has no way of knowing that record #2 has been locked while A's thread was napping(remember, you're past the if statement now), A goes ahead and locks record #2, effectively hijacking it from B. See the problem?

Hi Max,
Would it work if I synchronize the record number object (a Vector or a SortedSet)? By doing this, there is only one client can access this object at a time. What about two clients approach the object at the SAME point (rare situation, but possible?), who will get the object? How should I take care of this situation? Thank you
I just noticed that both Vector and SortedSet are not threadsafe in javadoc 1.4. So, should it be safer if we synchronize the Vector/SortedSet, instead of synchronize the lock and unlock methods, because I think if we synchronized the methods, it does not gurantee that at the same time multiple clients are not making changes in our record number Vector/SortedSet? Is this what they mean by "not threadsafe" for Vector and SortedSet? I am confused about the what I saw in the javadoc 1.4. Please advice..... Thanks

Just remember about the requirement that client A must not be allowed to unlock the record that was locked by client B. That's what makes it complex

Thank a lot.
But, I am confused about why Client B may be unlock the record locked by Client A? Thanks in advance!
I am new here, can someone give me some suggestions if my server side is threadsafe?
I implemented a SortSet to store the locked record number. So, when the record number is added to the SortSet, it means the record is currently locked. Then, I unlock the record by removing the record number from the SortSet. Whoever needs to lock the record needs to check if the record number is currently in the Set, if it is, the client needs to wait until the record is unlocked.
So, the operation will be like:
ClientA->lock (add record number into the SortedSet)->modify record->unlock (remove record number from the SortedSet)

Thanks very much
[ October 08, 2002: Message edited by: Salish Tankard ]