overload lock command? maybe others?

[not_a_commie]

I'd like to be able to overload the lock command so that I could log
an entry on lock and unlock. Any ideas on how to do this?

I think it would be powerful if you could inherit from a few keywords
in C# like this example:

static keyword MyLock : lock {
public MyLock(object obj) : base(obj) { log a message when entering
scope }
public ~MyLock() { log a message when going out of scope }
}

I could also see it being useful with the "using" keyword. I could see
it being very useful with try/catch/finally, but I think that would
conflict with the current method used for interrupting the code flow
(a painfully slow OS-level registration and interrupt).

 

[Barry Kelly]

I'd like to be able to overload the lock command so that I could log
an entry on lock and unlock. Any ideas on how to do this?

Create an object that implements IDisposable, and use

using (MyLock.Lock(foo))
{
}

.... instead.

E.g. roughly:

class MyLock : IDisposable
{
object _obj;

public MyLock(object obj)
{
_obj = obj;
if (_obj != null)
{
Monitor.Enter(_obj);
// logging
}
}

public void Dispose()
{
if (_obj != null)
{
Monitor.Exit(_obj);
// logging
}
_obj = null;
}
}

I could also see it being useful with the "using" keyword.

You can use the above idiom with 'using' too, by 'using' a proxy, and
passing the actual object to the constructor, and exposing it via a
property of the proxy.

I could see
it being very useful with try/catch/finally,

Another technique is to pass the code whose context you want to wrap as
an anonymous delegate. E.g.:

delegate void Proc();

static void MyWrapper(Proc proc)
{
try
{
proc();
}
catch (Exception ex)
{
// do something with ex, e.g. show a dialog
}
}

// ...

MyWrapper(delegate
{
// My code that might throw
});

but I think that would
conflict with the current method used for interrupting the code flow
(a painfully slow OS-level registration and interrupt).

-- Barry

 

[Brian Gideon]

Create an object that implements IDisposable, and use

using (MyLock.Lock(foo))
{

}

The C# team could have eliminated a keyword had they used that pattern
to begin with. It also would be less confusing for novice developers
who try to figure out the purpose of a Monitor.Pulse or Monitor.Wait
embedded in a lock block, not realizing that the lock keyword and the
Monitor class are intimately related. Why did they choose to create
the lock keyword anyway?

 

[Barry Kelly]

using (MyLock.Lock(foo))

class MyLock : IDisposable
{

Missing, is of course:

public static MyLock Lock(object obj)
{
return new MyLock(obj);
}

object _obj;

I've used this technique to get nice syntax for other primitives, such
as Mutex, ReaderWriterLock, etc.

-- Barry

 

[not_a_commie]

Thank you, Barry, very much. That was exactly what I needed to know. I
had not heard of the Monitor class, but that looks to be exactly what
I needed.

I can't see how this would apply to try/catch. It's too bad that the
try/catch stuff has to go all the way to the OS level to stop from
executing code. Here's the document MS responded with for my feedback
(id 256733) on the topic: http://www.microsoft.com/msj/0197/exception/exception.aspx

 

[Barry Kelly]

The C# team could have eliminated a keyword had they used that pattern
to begin with. It also would be less confusing for novice developers
who try to figure out the purpose of a Monitor.Pulse or Monitor.Wait
embedded in a lock block, not realizing that the lock keyword and the
Monitor class are intimately related. Why did they choose to create
the lock keyword anyway?

I read somewhere that AndersH regretted adding 'lock' after adding
'using'.

-- Barry

 

[Barry Kelly]

Thank you, Barry, very much. That was exactly what I needed to know. I
had not heard of the Monitor class, but that looks to be exactly what
I needed.

I can't see how this would apply to try/catch.

The second approach I listed, the delegate approach, can easily be
applied to try/catch. You pass the code as an anonymous delegate as an
argument.

It's too bad that the
try/catch stuff has to go all the way to the OS level to stop from
executing code.

I typically implement my event handlers inside anonymous delegates
passed to wrappers, as indicated in my grandparent post.

Alternatively, you can add a handler to either:

1) Application.ThreadException - for exceptions thrown during Windows
message processing, typically due to e.g. throwing an exception in a
control's event handler.

2) AppDomain.UnhandledException - for those exceptions that would
otherwise fall off the entire thread's stack.

-- Barry

 

[Jon Skeet [C# MVP]]

The C# team could have eliminated a keyword had they used that pattern
to begin with. It also would be less confusing for novice developers
who try to figure out the purpose of a Monitor.Pulse or Monitor.Wait
embedded in a lock block, not realizing that the lock keyword and the
Monitor class are intimately related. Why did they choose to create
the lock keyword anyway?

Because they were copying Java

Those following this thread may be interested in the locking classes
I've got in my utility library:

http://pobox.com/~skeet/csharp/miscutil/usage/locking.html

 

[not_a_commie]

Why did they choose to create

the lock keyword anyway?

To understand that one must first understand why we need a lower-case
"string" keyword.