Is there any advantage to locking individual objects representing a record rather than the collection of records. Should it be more efficient as you are less likely to get competing threads? What are the disadvantages? thank you guys!
I'm doing Contractors, not Hotel, but I expect the arguments are basically the same. I assume that by "locking" you're referring to synchronizing on a monitor, not "locking a record" as described in the assignment. They're not the same thing, though easily confused. E.g. when you execute lock(), you may enter and exit one or more synchonized blocks of code. When you exit lock(), all synchronized block have been exited, and you're no longer synced on anything - but the record is still considered "locked". -------- Record-level synchronization: PRO: Allows greater concurrency - different threads can operate on different records without contending for the same locks. Wait/notify is more efficient, as you can use notify rather than notifyAll, and you only notify a thread waiting for that particular record. CON: Some top-level synchronization is still needed. If collection of records is structurally modified (as by create()) then you really need to sync on the collection in order to know something like "how many records are there?" This leads to: Increased complexity. Can be alleviated with well-factored code and good documentation, but still a problem to some extent. Risk of deadlock. Be very careful about acquiring nested locks. -------- Top-level synchronization: PRO: Simpler to understand. Much less risk of deadlock. Just have everything that needs to sync on something, sync on the same object (probably "this" in the Data class, or whatever it's called for Hotels). CON: Reduced concurrency -> poorer performance. If any synchronized action blocks for some time (as when you read from a file, everyone else will have to wait for it. Wait/notify must rely on notifyAll, and all notified threads must check if the record that has become available is the one they were waiting for or not. -------- On balance, given that the specs emphasize simplicity for the benefit of those pesky junior programmers (who will probaby screw up the synchronization if the mess with it at all), and given that there's little mention of performance issues and my data file has only 29 records anyway - I think the case for top-level synchronization is stronger. I still want to use record-level synchronization because I keep imagining what happens if, despite the client's initial stated goals, the program ends up getting used years later for many more clients and records than originally anticipated. Happens all the time in the real world - our UBB software is an example. I'd like my software to scale well in this situation, and I think record-level synchronization will help considerably. But I'm not sure I can really justify it. And from comments elsewhere we know Max favors simplicity over performance for this assignment, so he'll probably favor top-level as well. And I'm less inclined to argue, this time. [ June 02, 2003: Message edited by: Jim Yingst ]
"I'm not back." - Bill Harding, Twister
Joined: May 08, 2003
thanks Jim, btw I was reading the spec again and it said that
Any attempt to lock a resource that is already locked should cause the current thread to give up the cpu, consuming no cpu cycles until the desired resource becomes available
James, Both blocks of code seem to be a block synchronized on object. You do have an extra wait in the second block, but there is nothing to compare it to. So the question "is the second better than the first" does not make sense to me. For the assignment, you will get more marks for writing clear, easy to read code than if you write something that is super efficient. In the old FBNS assignment this was explicit. In the new assignment it is not explicit, although they do say something like "use standard code unless you have a really good reason not to". how many questions can I ask in one sentence? Just as long as you do not use parenthesis in your questions (I suppose you can use them (but they can get really annoying (especially when they are overused (used too often (or out of context))))). Regards, Andrew