ILock, Disposable or Not?

[Troy Howard]

All,

Sergey has finished up the interfaces for the lucere.io.concurrency
namespace. One of the core interfaces, ILock, seems like it could
benefit from implementing IDisposable.

I'd like to open the discussion on that specific refactoring point.
Does this sound like a good idea? Can anyone envision any problems
with this?

My perspective is:

A lock seems like something that should be scoped very tightly.
Implementing IDisposable will allow me to define a critical region by
scoping a lock within a 'using' block. This is similar to the 'lock'
blocks we already have for multi-threading (aka 'synchronized' in
Java). It also means that if there is code written that is not careful
about releasing locks in a timely fashion, the GC will collect and
dispose of those locks for us when it's determined they've fallen out
of scope.

This all seems like an improvement over the current structure.

Thanks,
Troy

[Ayende Rahien]

+1

--
You received this message because you are subscribed to the Google Groups "Lucere" group.
To post to this group, send email to luc...@googlegroups.com.
To unsubscribe from this group, send email to lucere+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lucere?hl=en.

[Peter Mateja]

I don't see a problem with this.  Concrete implementations can always choose to do nothing if required... i.e. if a lock for some reason needs to survive / persist longer than the lock object.  I can't imagine that this would ever be necessary in the Lucene source though.

Peter Mateja
peter....@gmail.com