How to check if I own a monitor
Rüdiger Klaehn
is there a way to check if the current thread owns a monitor? I have
an internal method that assumes that it is always called when a
monitor is held by the current thread. Of course I could just lock on
this again, but I want to a) avoid the overhead for this and b)
validate that the caller fulfills the contract.
By the way: is there a separate news group for multithreading
questions?
best regards,
Rüdiger
---
public void PublicMethod()
{
lock(mLock) {
PrivateMethod();
}
}
// this method should only be called with a lock on mLock by the
current thread.
private void PrivateMethod()
{
Debug.Assert( /* the current thread has a lock on mLock */);
// do something short that requires synchronization
}
private readonly object mLock=new object();
Peter Duniho
<rkl...@googlemail.com> wrote:
> is there a way to check if the current thread owns a monitor?
Not per se, AFAIK.
> I have
> an internal method that assumes that it is always called when a
> monitor is held by the current thread. Of course I could just lock on
> this again, but I want to a) avoid the overhead for this and b)
> validate that the caller fulfills the contract.
What contract? The code you posted that deals with the actual lock seems
to be private within a class. Isn't it enough to just write the code
correctly? You're not publishing some kind of API, right?
As for locking again, if you've already got the lock, "locking" shouldn't
be a serious performance issue. I doubt there's any real "overhead" that
would cause a significant problem (i.e. whatever overhead exists
internally to the Monitor class, it's the same kind of overhead the
Monitor class would have if it could report whether you had the lock or
not). In fact, if you have a method that requires the caller to obtain
the lock, it seems debatable as to whether the caller really ought to be
responsible for the lock at all; maybe the lock really does belong inside
the method with the requirement, and not the caller.
If you want to be able to report an error, I think you'll have to keep
track of whether you have the lock or not yourself. For example, maintain
a boolean variable that's set to "true" only when you have the lock. For
bonus points, you could implement a Monitor wrapper that delegated the
actual lock operations to Monitor, but also kept track of whether the lock
was held, and exposed a property to that effect.
> By the way: is there a separate news group for multithreading
> questions?
Specifically for .NET? Not as far as I know.
Pete
Rüdiger Klaehn
wrote:
> On Sat, 20 Jun 2009 03:30:17 -0700, Rüdiger Klaehn
>
> > is there a way to check if the current thread owns a monitor?
>
> Not per se, AFAIK.
>
> > I have
> > an internal method that assumes that it is always called when a
> > monitor is held by the current thread. Of course I could just lock on
> > this again, but I want to a) avoid the overhead for this and b)
> > validate that the caller fulfills the contract.
>
> What contract? The code you posted that deals with the actual lock seems
> to be private within a class. Isn't it enough to just write the code
> correctly?
>
code correctly... I should have thought about that. :-)
> You're not publishing some kind of API, right?
>
No. The whole point is to have a way to check that I correctly
acquired the monitor. I still think there should be a method for this,
unless it is extremely difficult to implement.
Peter Duniho
<rkl...@googlemail.com> wrote:
> [...]
> No. The whole point is to have a way to check that I correctly
> acquired the monitor. I still think there should be a method for this,
> unless it is extremely difficult to implement.
As I wrote, if you have code where you know the lock is always required,
then creating some mandate that the _caller_ acquire the lock for you
seems silly to me. Just acquire the lock where you need it. Monitors are
re-entrant, and if there's any performance issues with respect to
re-entering the lock (and I doubt there is), you'd have the exact same
performance issue simply inspecting the lock to see whether you own it or
not.
Again, while there's no support for this in the Monitor class itself, it
would be trivial for you to write a custom lock class that provided that
feature, if you still think you really need it. It's my opinion you
don't, but if you insist I'm not going to spend a lot of time trying to
dissuade you.
Pete