Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

A locking idea  RSS feed

 
Sean Brown
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't know if it's new, but I have a new-to-me locking idea.
I was hoping to get your advice on it.

So, it's a simple lock which is acquired and released.
Acquisition is just through the acquire() method, which returns a lock instance.
The unique part is that there is no release method; release is effected by 'losing' the lock instance, ie making it GC reclaimable.
The actuator which holds the acquire() method keeps a Reference to the lock instance and checks it upon future acquire()s.

What I'm not sure about is how reliable is the garbage collector in clearing Reference objects implicitly and explicitly through System.gc()

I posted this in the Threads and Synchronization forum to get your thoughts on it and to know if it had been done before, and if so, did it work?
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't know if it has been tried before, but I don't know exactly what the point would be. Why is this a good idea? What problems does it solve?
 
Carey Evans
Ranch Hand
Posts: 225
Debian Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In general, there�s no guarantee that an unreferenced object will ever be garbage-collected, or that its finalizer will be called promptly. Garbage collection also varies significantly between different VMs from different vendors, so something that worked on your 1- or 2-core desktop today might not work on an 8-core server tomorrow.

I�m afraid I don�t think your proposal will work on a Java Virtual Machine.
 
Pat Farrell
Rancher
Posts: 4686
7
Linux Mac OS X VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Sean Brown]The unique part is that there is no release method; release is effected by 'losing' the lock instance,


I don't understand the point of this. The lock/free mechanism has been in use for 40+ years. Its well understood, and reliable.

If you want to do something close to this with a function, you can just declare it "synchronized" and it is locked when you enter, and released when you leave.

The concurrency tools added in Java 1.5 are just more explicit and a bit more flexible.

The foundations were done by Hoare and Djkstra long long ago
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One basic idea of locks is to define clear points at which the lock is acquired and released.
If the point of release of lock is determined by GC then it will add a whole lot uncertainity to the system. No one one will be able to predict as to when a lock will be released, debugging will be nearly impossible and synchronization will not add any value to the entire scheme.

On the other hand, putting such a logic may be a little fruitful for closing file objects. I dont remember exactly but sometime back i saw some proposals for changes in Java where implicit file closing can be done by specifying a file object for a block.
 
Vaibhav Jaiswal
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is not a new idea it is how locking was done in older days, you lock a critical section-> modify the resource -> unlock the critical section. As in C++ destructors run as soon as the object goes out of scope so normally wrapper classes are written so that an object is created(the constructor is passed the criti which it locks)at the start and left to be unlocked by the destructor.
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!