42
Originally posted by Jeroen T Wenting:
no, locking and threading have little to do with one another (though locking does help keeping the threading code performant).
You can have locking and still not be threadsafe, and you could provide threadsafe code without locking.
The lock is to prevent one client to attempt a modification to a record while another client is doing so.
That's a far more coarse grained operation than a lock which prevents multiple threads from gaining access to the same program resources.
The logical lock you program on a record can hold against a broad range of resources simultaneously, resources that are completely unrelated to the work that goes on by synchronising on something.
You could for example write code to enable simultaneous reading and writing to the database using a record level lock to prevent simultaneous updating.
You could never do that by synchronising database access on the file, as that would prevent concurrent access to the entire file.
Originally posted by Joe Zhou:
Simply putting the IO access code may not guarantee the IO operation is thread-safe. That is why lock()/unlock() are required. Right?
Originally posted by Joe Zhou:
Think that if 'synchronize' can solve all the problems, there is no need to implement the lock()/unlock(). It is not a sense of logic locking. It is something a must to make your code thread-safe.
Hope I am correct.
42
Originally posted by Joe Zhou:
To thread-safe your update():
lock(recNo);
update(recNo);//no need synchronize this block.
unlock(recNo);
My testing shows OK. You may synchronize the context in your update(). It won't hurt. Good luck.
Originally posted by Joe Zhou:
for sure, lock.wait() will block till it is notified. This is the most interesting part of the assignment.
If your thread holds the lock then, for sure, lock.wait() will block till it is notified. This is the most interesting part of the assignment.
As in the one argument version, interrupts and spurious wakeups are possible, and this method should always be used in a loop:
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
What if
Thread 1 writes partially to rec#1
Thread 2 writes partially to rec#2
..
Thread1 comes back to write the rest. Where would be your file pointer ???
As in the one argument version, interrupts and spurious wakeups are possible, and this method should always be used in a loop:
Good point. If waiting is interrupted, it should be a failure and let it be handled by the exception handler. Make sense??
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
Not so sure about this scenario. I think each thread should have it's own file pointer.
42
Originally posted by Joe Zhou:
I am wondering you two are fresh graduate. I see you are using so much theories from school. I feel sad that I have left from school for so long.
What I am doing is coding the project as the specification and testing the code according to the project requirements. I would never finish my assignment if I dig into the theories so deep. Hope this is not too superising.
The file pointer is the position in the file where you're currently reading or writing.
you can't read from/write to a file at more than one position at a time...
That is right. Can different threads have different file pointers? I think the answer is YES. Back to the locking above, if different threads work on different records and each has it's own file pointer, then there is nothing to worry about since they are writing data to different track/cylinder/segment. Remember that JVM will take care all the stuff about writing your data to the disc(CS303/CS304 "File Structure" right?).
If threads are working on the same record, then there is a risk that the record is over written by the threads. That is why the lock/unlock is required. When a record is locked, there will be only one thread writing data to that record. So this is the reason for the locking(not for the logic). Locking is not to make sure the file pointer working properly. Again file pointer is controlled by the JVM and your operating system, Windows XXX probably. By the other word, how your data/record is written to disc is not controlled by your code. It is by JVM. You don't worry about it.
Now, you see I did complete my school... not dropped out right;-)
42
-------------------------<br />SCSA,SCNA,SCJP,SCEA
In the past Sun has displayed information on its web site indicating that use of the NIO packages was not allowed in the SCJD assignment.
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
-------------------------<br />SCSA,SCNA,SCJP,SCEA
Originally posted by Marco Santinon:
How can these two specifications work together?
Marco
Ask a Meaningful Question and HowToAskQuestionsOnJavaRanch
Getting someone to think and try something out is much more useful than just telling them the answer.
42
SCJP 1.4
Consider Paul's rocket mass heater. |