Excuse me if this has been addressed before, I am little crazy right now .
I was wondering how you guys handled the concurrency between the find & create methods.
I currently have the find method iteration over the "cache" object synchronized, which means I need to synchronize
the put on the cache in the create method. This bothers me because technically on a search, only one thread would be able to perform
that operation at a time, when no "creates" are ongoing. (Its like synchronizing the find method completely and only allowing 1 thred to access it at a time) I was wondering if that concerned anybody and how you handled it
I didn't bother at all: every method is marked synchronized, so yes only 1 thread at a time can perform a method. It's not that performant, but it's a very easy approach. If you want your application to be more performant, you can work with synchronized blocks instead.
Thanks for the response... Actually, I am working with synchronized blocks just for that reason, because synchronizing the methods
only provides so much protection. You still have to provide synchronized blocks right?
Thread 1 ---> inside synchronized method 1 iterating through object a
Thread 2 --> inside synchornized method 2 modifying object a
This scenario has the possibility of concurrentmodification exception.
If you synchronize the complete method I don't see why you would need to provide synchronization blocks. So that's not right at all! If thread1 is in synchronized methodA of objectX, then thread2 (which wants to execute synchronized methodB of objectX) simply has to wait until thread1 has finished executing methodA.
lock method -- synchronizes on the room object
unlock -- synchronizes on the room
find -- synchronizes on the data cache
create -- synchronizes on the data cache
Do you think it would be better to try and synchronize the lock method on (this)? as well as all teh other methods.... My locking mechanism
is performing quite well... no deadlocks, but I am concerned that there might be something i missed.. that chance of throwing that exception or
Seems a weird approach. You would expect that your lock/unlock methods synchronize (at leadt) on the map with locked records, because that's the structure you are reading from and writing to, so you would not want that to be changed from another thread while you are manipulating this structure.
I would advice to synchronize all methods on the same object (this) instead of every method synchronizing on another object, just for the sake of simplicity. This might be a bit less performant, but according to the instructions simplicity is preferred above performance.
Roel De Nijs wrote:I would advice to synchronize all methods on the same object (this) instead of every method synchronizing on another object, just for the sake of simplicity. This might be a bit less performant, but according to the instructions simplicity is preferred above performance.
That's what I did, with a comment in my choices document that I'd revisit it if load testing showed there was a performance problem.
posted 8 years ago
I think it was just a little hard to follow...
I was synchronizing sometimes on multiple objects, as you said, the lockedRecords map, and the room object, the datacache, sometimes multiple in an method... but overall, I had no deadlocks, and the performance was great.... but it does leave an opening for holes... and when someone comes in to maintain
that, they might move something and not necessarily understand why I did what I did.
I switched to synchronizing on this and although it looks good from a deadlock standpoint, it is much slower... no matter..
But your right, and its somethign I should have just done from the beginning, which is make it simple.. Thank you two for the help.
There is no beard big enough to make me comfortable enough with my masculinity to wear pink. Tiny ad:
Devious Experiments for a Truly Passive Greenhouse!