Suggestion for C#

[Allan Ebdrup]

I have a suggestion for C#
I would like reader/writer locks to be built in to the language.
When you want to aquire a loct on an object o you write
lock(o)
{
...//critical region
}

I would like to be able to write:
readlock(o)
{
...//critical region that only reads shared data
}

Behind the scenes, the first time readlock(o) was called, the locking
mechanism on o would be upgraded to a reader/writer lock and any active,
queued or future locks on o acqired by using lock(o) would become writer
locks.
That way there would be no difference for the programmer between usind a
reader/write lock and a normal lock, all you would need to know would be
that if you want to read and write shared data you use lock(o) and if you
only want to read shared data you just use readlock(o).

It may be feasible to downgrade the reader/writer lock to a normal lock
again if only lock(o) has been used for a long time with no readlock(o)'s
beeing called.

Reader/writer locks are very common and this approach would not force the
programmer to choose between a normal lock or a reader/writer lock, they
would be the same. Furthermore with my suggestion there would be no need for
creating a reader/writer lock object and creating try finally blocks etc.
The syntax is much easier to use.

If this is not the right place to post my suggestion, where do I send my
suggestion?

Kind Regards,
Allan Ebdrup

[Jon Skeet [C# MVP]]

On May 31, 9:50 am, "Allan Ebdrup" <ebd...@noemail .noemailwrote:

I have a suggestion for C#
I would like reader/writer locks to be built in to the language.

I'd definitely disagree with that idea. I'd prefer locks not to be
part of the language at all - the "using" statement with appropriate
locking types is all that's required.

<snip>

Reader/writer locks are very common

I can't remember the last time I used one, and I've done plenty of
multi-threaded code. Normally you can release the lock sufficiently
quickly that it's more efficient to just use a "normal" lock than to
use the heavier ReaderWriterLoc k. There's going to be a slimmer RW-
lock in .NET 3.5, but even so, I wouldn't want it in the language.
Where possible, the language should (IMO) avoid having dependencies on
the framework. There are exceptions, but they should be tightly
controlled.

Furthermore with my suggestion there would be no need for
creating a reader/writer lock object and creating try finally blocks etc.
The syntax is much easier to use.

A "using" statement is very easy to use.
See http://pobox.com/~skeet/csharp/miscu...e/locking.html for an
example - it could easily be expanded to have methods which take out a
ReaderWriter lock, or to have different types which would do that
appropriately.

If this is not the right place to post my suggestion, where do I send my
suggestion?

connections.mic rosoft.com is the normal place for suggestions and bug
reports. It's a good idea to get peer review on newsgroups first
though, so the suggestion can be "tuned" before submission.

Jon

[Jon Skeet [C# MVP]]

On May 31, 9:50 am, "Allan Ebdrup" <ebd...@noemail .noemailwrote:

Just thinking about this further:

<snip>

Behind the scenes, the first time readlock(o) was called, the locking
mechanism on o would be upgraded to a reader/writer lock and any active,
queued or future locks on o acqired by using lock(o) would become writer
locks.

How would you expect that to work? The C# compiler still has to
produce "normal" framework code - if this is just syntactic sugar,
could you write the current C# equivalent which would upgrade the lock
in one thread from a simple monitor lock to a reader/writer lock when
a read-only lock was required in a different thread?

Jon

[Marc Gravell]

It is certainly a valid place to *discuss* it, but "connect" is
probably better for a proposal - but this would need a lot more
work... for instance, there is a big difference between how
ReaderWriterLoc k and Monitor (=lock at the moment) work - Monitor uses
part of the targetted object, but ReaderWriterLoc k is itself an
object. The two would not be compatible at all.

Monitor tends to be significantly more lightweight, so a syntax change
for this to use a "write" ReaderWriterLoc k would be a huge change -
but that is the only way it could possibly be compatible when you
consider re-entrancy, sub methods etc. Likewise, this wouldn't support
Pulse etc.

In short - I can't see it being feasible, and in most cases I can't
see a reason to try. In most scenarios, Monitor is more than adequate.
In those scenarios where you really do want parallel concurrent
access, the existing ReaderWriterLoc k syntax works. I can't remember
the "who" or the exact quote, but a good rule of thumb is: if you want
to make a change like this, it had better be *much* better, otherwise
it isn't worth it. In this case, I'm not sure that it is.

IMHO

Marc

[Mark Rae]

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:11******** **************@ q75g2000hsh.goo glegroups.com.. .

>I would like reader/writer locks to be built in to the language.

I'd definitely disagree with that idea. I'd prefer locks not to be
part of the language at all - the "using" statement with appropriate
locking types is all that's required.

Agreed 100%.

>Reader/writer locks are very common

I can't remember the last time I used one, and I've done plenty of
multi-threaded code.

Likewise, on both counts...
--
http://www.markrae.net

[Jon Skeet [C# MVP]]

On May 31, 10:06 am, "Jon Skeet [C# MVP]" <[e-mail] wrote:

<snip>

connections.mic rosoft.com is the normal place for suggestions and bug
reports.

Oops - as Marc pointed out, it's connect.microso ft.com.

Jon

[Allan Ebdrup]

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:11******** **************@ q75g2000hsh.goo glegroups.com.. .

On May 31, 9:50 am, "Allan Ebdrup" <ebd...@noemail .noemailwrote:

>I have a suggestion for C#
I would like reader/writer locks to be built in to the language.

I'd definitely disagree with that idea. I'd prefer locks not to be
part of the language at all - the "using" statement with appropriate
locking types is all that's required.

<snip>

>Reader/writer locks are very common

I can't remember the last time I used one, and I've done plenty of
multi-threaded code. Normally you can release the lock sufficiently
quickly that it's more efficient to just use a "normal" lock than to
use the heavier ReaderWriterLoc k. There's going to be a slimmer RW-
lock in .NET 3.5, but even so, I wouldn't want it in the language.
Where possible, the language should (IMO) avoid having dependencies on
the framework. There are exceptions, but they should be tightly
controlled.

I see what you mean, I do use reader/writer locks for caching data that is
read very often in somewhat heavy operations and very seldom written. I
still like the idea of not having to choose wether you use a normal lock or
a reader/writer lock, and just upgrading the locking mecanism if needed.

>Furthermore with my suggestion there would be no need for
creating a reader/writer lock object and creating try finally blocks etc.
The syntax is much easier to use.

A "using" statement is very easy to use.
See http://pobox.com/~skeet/csharp/miscu...e/locking.html for an
example - it could easily be expanded to have methods which take out a
ReaderWriter lock, or to have different types which would do that
appropriately.

good example. I'm not sure what mean by the last part. Do you mean that you
could make code that upgrades from a normal lock to a reader/writer lock?

Kind Regards,
Allan Ebdrup

[Allan Ebdrup]

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:11******** **************@ q75g2000hsh.goo glegroups.com.. .

On May 31, 9:50 am, "Allan Ebdrup" <ebd...@noemail .noemailwrote:

Just thinking about this further:

<snip>

>Behind the scenes, the first time readlock(o) was called, the locking
mechanism on o would be upgraded to a reader/writer lock and any active,
queued or future locks on o acqired by using lock(o) would become writer
locks.

How would you expect that to work? The C# compiler still has to
produce "normal" framework code - if this is just syntactic sugar,
could you write the current C# equivalent which would upgrade the lock
in one thread from a simple monitor lock to a reader/writer lock when
a read-only lock was required in a different thread?

I'm pretty sure it could be done. But I don't have a solution in mind.

[Jon Skeet [C# MVP]]

On May 31, 10:33 am, "Allan Ebdrup" <ebd...@noemail .noemailwrote:

I can't remember the last time I used one, and I've done plenty of
multi-threaded code. Normally you can release the lock sufficiently
quickly that it's more efficient to just use a "normal" lock than to
use the heavier ReaderWriterLoc k. There's going to be a slimmer RW-
lock in .NET 3.5, but even so, I wouldn't want it in the language.
Where possible, the language should (IMO) avoid having dependencies on
the framework. There are exceptions, but they should be tightly
controlled.

I see what you mean, I do use reader/writer locks for caching data that is
read very often in somewhat heavy operations and very seldom written.

But how long does fetching the data take anyway, and how much
concurrency do you expect? If it's quick, it could well be that using
a ReaderWriter lock is still more expensive than a plain exclusive
monitor lock.

I still like the idea of not having to choose wether you use a normal lock or
a reader/writer lock, and just upgrading the locking mecanism if needed.

It would be a nice idea if it were feasible - but I don't *think* it
is.

A "using" statement is very easy to use.
Seehttp://pobox.com/~skeet/csharp/miscutil/usage/locking.htmlfor an
example - it could easily be expanded to have methods which take out a
ReaderWriter lock, or to have different types which would do that
appropriately.

good example. I'm not sure what mean by the last part. Do you mean that
you could make code that upgrades from a normal lock to a reader/writer
lock?

I don't think it could upgrade an existing, held lock into a reader/
writer lock. With *very* carefully defined semantics it might be
possible to work something out, but I'm not entirely sure. I don't
think it's worth the extra work though, personally.

Jon

[Moty Michaely]

On May 31, 12:09 pm, "Jon Skeet [C# MVP]" <[e-mail] wrote:

On May 31, 9:50 am, "Allan Ebdrup" <ebd...@noemail .noemailwrote:

Just thinking about this further:

<snip>

Behind the scenes, the first time readlock(o) was called, the locking
mechanism on o would be upgraded to a reader/writer lock and any active,
queued or future locks on o acqired by using lock(o) would become writer
locks.

How would you expect that to work? The C# compiler still has to
produce "normal" framework code - if this is just syntactic sugar,
could you write the current C# equivalent which would upgrade the lock
in one thread from a simple monitor lock to a reader/writer lock when
a read-only lock was required in a different thread?

Jon

Jon,

I agree 100%.

Where possible, the language should (IMO) avoid having dependencies on
the framework. There are exceptions, but they should be tightly
controlled.

I would say that the language should try to avoid as much as it can
having dependencies of any kind :).

Moty