By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,854 Members | 849 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,854 IT Pros & Developers. It's quick & easy.

Suggestion for C#

P: n/a
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
May 31 '07 #1
Share this Question
Share on Google+
20 Replies


P: n/a
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 ReaderWriterLock. 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.microsoft.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

May 31 '07 #2

P: n/a
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

May 31 '07 #3

P: n/a
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
ReaderWriterLock and Monitor (=lock at the moment) work - Monitor uses
part of the targetted object, but ReaderWriterLock 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" ReaderWriterLock 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 ReaderWriterLock 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
May 31 '07 #4

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@q75g2000hsh.googlegr oups.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

May 31 '07 #5

P: n/a
On May 31, 10:06 am, "Jon Skeet [C# MVP]" <s...@pobox.comwrote:

<snip>
connections.microsoft.com is the normal place for suggestions and bug
reports.
Oops - as Marc pointed out, it's connect.microsoft.com.

Jon

May 31 '07 #6

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@q75g2000hsh.googlegr oups.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 ReaderWriterLock. 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
May 31 '07 #7

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@q75g2000hsh.googlegr oups.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.
May 31 '07 #8

P: n/a
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 ReaderWriterLock. 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

May 31 '07 #9

P: n/a
On May 31, 12:09 pm, "Jon Skeet [C# MVP]" <s...@pobox.comwrote:
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

May 31 '07 #10

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11*********************@p47g2000hsd.googlegro ups.com...
On May 31, 10:33 am, "Allan Ebdrup" <ebd...@noemail.noemailwrote:
>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.
In one case fetching the data and updating the data (writer lock) takes
several minutes
Reading the data is called from many threads and the readlock is held for
several seconds on each thread.
>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.
Don't be so pessimistic, almost anything is possible.
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.
That's why I want MS to do the work ;-), it only has to be done once.

Kind Regards,
Allan Ebdrup
May 31 '07 #11

P: n/a
On May 31, 11:31 am, "Allan Ebdrup" <ebd...@noemail.noemailwrote:
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.

In one case fetching the data and updating the data (writer lock) takes
several minutes
Reading the data is called from many threads and the readlock is held for
several seconds on each thread.
Right. I'd say that's a fairly unusual situation - I rarely need to
hold locks for that long.
It would be a nice idea if it were feasible - but I don't *think* it
is.

Don't be so pessimistic, almost anything is possible.
Not within C# itself. If there were a CLR change as well, it might be
possible. That's clearly a much bigger task though, and I don't think
it's worth the effort.
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.

That's why I want MS to do the work ;-), it only has to be done once.
I think there are other features I'd be much more interested in MS
working on, to be honest.

Jon

May 31 '07 #12

P: n/a
"Moty Michaely" <Mo*****@gmail.comwrote in message
news:11**********************@h2g2000hsg.googlegro ups.com...
On May 31, 12:09 pm, "Jon Skeet [C# MVP]" <s...@pobox.comwrote:
>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 :).
I agree that adding the feature to the language was a bad idea.
But I still like the idea of it beeing possible to upgrade a lock from a
monitor to a ReaderWriterLock if needed.
I guess I don't see why more work wasn't put into having those two locking
mechanisms behave more simular, seems to me that a ReaderWriterLock might as
well work on an object like a Monitor and might as well have Pulse so they
are more simular. Maybe I'm missing something but would Pulse on a
ReaderWriterLock not make sense? And would a ReaderWriterLock that works on
an object like Monitor not make sense?

Kind Regards,
Allan Ebdrup
May 31 '07 #13

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11*********************@h2g2000hsg.googlegrou ps.com...
I think there are other features I'd be much more interested in MS
working on, to be honest.
You could always suggest it to Anders next time you do lunch... ;-)
--
http://www.markrae.net

May 31 '07 #14

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11*********************@p47g2000hsd.googlegro ups.com...
On May 31, 10:33 am, "Allan Ebdrup" <ebd...@noemail.noemailwrote:
>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.
Well differentiating between a normal lock and a read/write lock could be
arranged easily enough. Something like lock(obj), readLock(obj),
writeLock(obj). Read and write locks could only be done on a custom
'ReadWriteLock' class. The code itself for a (albeit very VERY basic)
read/wrtie lock would just be a counter incremented for each reader
currently locking.
May 31 '07 #15

P: n/a
Dave <fa*******@dodo.com.auwrote:
It would be a nice idea if it were feasible - but I don't *think* it
is.

Well differentiating between a normal lock and a read/write lock could be
arranged easily enough. Something like lock(obj), readLock(obj),
writeLock(obj). Read and write locks could only be done on a custom
'ReadWriteLock' class. The code itself for a (albeit very VERY basic)
read/wrtie lock would just be a counter incremented for each reader
currently locking.
But Allan's suggestion requires "upgrading" from a cheap mutex lock to
a reader/writer lock - and that's the tricky bit, IMO.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
May 31 '07 #16

P: n/a
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote:
On May 31, 9:50 am, "Allan Ebdrup" <ebd...@noemail.noemailwrote:
>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.
At the other end of the spectrum, I use ReaderWriter locks quite a bit.

Our stuff runs on alot of multi-core and multi-processor machines, and we
actually end up with alot of lock contention as a result. I believe in most
multi-threaded apps, true lock contention is actually pretty rare and
locking is more for preventing corner cases and race conditions - so
Monitors work very well.

When I ran the profiler on an 16 processor (64GB of Memory) IA64 box, it
quickly became apparent that Monitor's were not going to cut it any longer.
We then switched our key datastructures over to use ReaderWriterLocks, and
things improved dramatically.

One of my frustrations here is the lack of a good overall solution. When I
was doing this profiling, I tried 3 solutions for locking around our various
stacks and queues:
Solution 1 - Monitors
Solution 2 - ReaderWriterLocks
Solution 3 - Lock Free Code

On a small box (1 or 2 processors) we saw:
- Monitors were clearly the best.
- ReaderWriterLocks were ok.
- Lock Free Stuff was slowest.

On meduim boxes (4 or 8 processors) we saw:
- Monitors were ok.
- ReaderWriterLocks were better.
- Lock Free Stuff was somewhere in between.

On big boxes (16 processors) we saw:
- Monitors Sucked
- ReaderWriterLock was ok.
- Lock Free was awesome.

(These results were across a mixture of x86, x64 and IA64 machines. I really
wish I had been more methodical in recording my results, as it would have
made a great blog entry....)

These results were very tied to our use cases - adding (and removing) data
to a queue for processing, checking for cache hits, expiring a cache,
updating a chache, and some other related cases.

There were 4 or 5 spots that really stood out as "Contention here!", and
this is where changing the lock structures made a difference. For the vast
majority of the locking we do, Monitors are the solution.

I've always wanted to "Write a smart locking class, that checks the
processor count at runtime, then uses the right lock & datastructure."

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins
May 31 '07 #17

P: n/a
I should mention the scales I'm talking about as well - if you're dealing
with small scale applications, everything I'm talking about is a waste of
time and you should just use whatever locking mechanism you and your team
understand the best (typically Monitors).

In the tests I described in the last post, we had 250,000 TCP connections
coming into a single server, with each connection actively sending and
receiving traffic.

This traffic is XMPP traffic, which means UTF-8 to UTF-16 encoding changes,
Xml Stanza ReAssembly (due to receive chunking), Xml Processing, Z-Lib
Compression, TLS Encryption, and a boatload of processing (Are my friends
online? Send me their status. Is anyone registred to be looking for me? Send
them my status. Do I have any offline messages pending? Send 'em over. Do I
have any offline events pending? Send them too. Gimme all my friends
Avatar's [even if they're offline, it should still be the newest avatar they
published], etc.)

I'm really looking forward to the networking improvements that Orcas brings.
The new Overlapped datastructures alone should give us a 50%+ boost in
scalability on comparable hardware....

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

"Chris Mullins [MVP]" <cm******@yahoo.comwrote in message
news:er**************@TK2MSFTNGP02.phx.gbl...
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote:
>On May 31, 9:50 am, "Allan Ebdrup" <ebd...@noemail.noemailwrote:
>>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.

At the other end of the spectrum, I use ReaderWriter locks quite a bit.

Our stuff runs on alot of multi-core and multi-processor machines, and we
actually end up with alot of lock contention as a result. I believe in
most multi-threaded apps, true lock contention is actually pretty rare and
locking is more for preventing corner cases and race conditions - so
Monitors work very well.

When I ran the profiler on an 16 processor (64GB of Memory) IA64 box, it
quickly became apparent that Monitor's were not going to cut it any
longer. We then switched our key datastructures over to use
ReaderWriterLocks, and things improved dramatically.

One of my frustrations here is the lack of a good overall solution. When I
was doing this profiling, I tried 3 solutions for locking around our
various stacks and queues:
Solution 1 - Monitors
Solution 2 - ReaderWriterLocks
Solution 3 - Lock Free Code

On a small box (1 or 2 processors) we saw:
- Monitors were clearly the best.
- ReaderWriterLocks were ok.
- Lock Free Stuff was slowest.

On meduim boxes (4 or 8 processors) we saw:
- Monitors were ok.
- ReaderWriterLocks were better.
- Lock Free Stuff was somewhere in between.

On big boxes (16 processors) we saw:
- Monitors Sucked
- ReaderWriterLock was ok.
- Lock Free was awesome.

(These results were across a mixture of x86, x64 and IA64 machines. I
really wish I had been more methodical in recording my results, as it
would have made a great blog entry....)

These results were very tied to our use cases - adding (and removing) data
to a queue for processing, checking for cache hits, expiring a cache,
updating a chache, and some other related cases.

There were 4 or 5 spots that really stood out as "Contention here!", and
this is where changing the lock structures made a difference. For the vast
majority of the locking we do, Monitors are the solution.

I've always wanted to "Write a smart locking class, that checks the
processor count at runtime, then uses the right lock & datastructure."

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

May 31 '07 #18

P: n/a
Chris Mullins [MVP] <cm******@yahoo.comwrote:
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote:
On May 31, 9:50 am, "Allan Ebdrup" <ebd...@noemail.noemailwrote:
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.

At the other end of the spectrum, I use ReaderWriter locks quite a bit.

Our stuff runs on alot of multi-core and multi-processor machines, and we
actually end up with alot of lock contention as a result. I believe in most
multi-threaded apps, true lock contention is actually pretty rare and
locking is more for preventing corner cases and race conditions - so
Monitors work very well.

When I ran the profiler on an 16 processor (64GB of Memory) IA64 box, it
quickly became apparent that Monitor's were not going to cut it any longer.
We then switched our key datastructures over to use ReaderWriterLocks, and
things improved dramatically.
Are you hoping to move to .NET 3.5 any time soon? I'd expect that with
the "slim" reader/writer lock, it should get better again.

Interesting reading about your experiences with other solutions - not
entirely surprising, but annoying, as you say...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
May 31 '07 #19

P: n/a
I hope so, but it's really up in the air at this point.

The problem is that our Client and Server are both built on top of the same
SDK - and that SDK needs to be able to run anywhere .Net 2.0 is installed.
The SDK is what sits on top of the sockets, reads the Xml, and turns Xml
Stanzas into instances of .Net classes. This needs to keep running on top of
the .Net 2.0 CLR, as that's installed in a lot of spots.

For the "server" portions of the codebase (the stuff that sits on top of the
SDK), switching to .Net 3.5 will happen as soon as Orcas goes live. The
networking improvements alone will justity it. I'm really hoping we can
continue to use the same code base, and see the improvements. Ideally the
same 2.0 assemblies, when run in the 3.5 CLR, will get the networking
improvements (specifically, the improvements to the Overlapped
datastructures, which is what really hobbled us last time).

I also want to go the route Richter went in his Power Threading library -
he's got an abstraction layer for his locks, so it's really easy to switch
out the lock types, with ReaderWriterLockSlim being one of the first things
to try.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..
Chris Mullins [MVP] <cm******@yahoo.comwrote:
>"Jon Skeet [C# MVP]" <sk***@pobox.comwrote:
On May 31, 9:50 am, "Allan Ebdrup" <ebd...@noemail.noemailwrote:
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.

At the other end of the spectrum, I use ReaderWriter locks quite a bit.

Our stuff runs on alot of multi-core and multi-processor machines, and we
actually end up with alot of lock contention as a result. I believe in
most
multi-threaded apps, true lock contention is actually pretty rare and
locking is more for preventing corner cases and race conditions - so
Monitors work very well.

When I ran the profiler on an 16 processor (64GB of Memory) IA64 box, it
quickly became apparent that Monitor's were not going to cut it any
longer.
We then switched our key datastructures over to use ReaderWriterLocks,
and
things improved dramatically.

Are you hoping to move to .NET 3.5 any time soon? I'd expect that with
the "slim" reader/writer lock, it should get better again.

Interesting reading about your experiences with other solutions - not
entirely surprising, but annoying, as you say...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

May 31 '07 #20

P: n/a
Hi Allan,

I would recommend you to submit a suggestion at the link below:
https://connect.microsoft.com/VisualStudio

Our product team will follow up with your suggestion, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Jun 4 '07 #21

This discussion thread is closed

Replies have been disabled for this discussion.