对C＃的建议 [英] Suggestion for C#

问题描述

我有一个C＃

的建议我希望读者/作者锁可以内置到该语言中。

当你想在一个对象上获取一个loct o你写的

lock（o）

{

... //关键区域

}


我希望能写：

readlock（o）

{

.. .//仅读取共享数据的关键区域

}


在幕后，第一次调用readlock（o）时，锁定

机制将被升级为读取器/写入器锁定，任何活动的，/ b $ b排队或将来使用锁定（o）获得的锁定将成为作者

锁定。

那样程序员在使用

读卡器/写锁和普通锁之间没有任何区别，所有你需要知道的就是如果您想要读取和写入共享数据，请使用lock（o），如果您只需要读取共享数据，则只需使用readlock即可。
（o）。


如果只使用锁（o），将读写器锁定降级到正常锁定

可能是可行的很长一段时间没有readlock（o）'s $
beeing叫。


读/写锁非常常见，这种方法不会强迫<程序员可以在正常锁定或读写器锁定之间进行选择，它们将是相同的b $ b。此外，根据我的建议，不需要创建读取器/写入器锁定对象并创建try finally块等等。

语法更容易使用。 />

如果这不是发布我的建议的正确位置，我在哪里发送我的

建议？


种类此致，

Allan Ebdrup

解决方案

5月31日上午9:50，Allan Ebdrup < ebd ... @ noemail.noemailwrote：

我对C＃有建议

我想读/写锁是内置于语言中。

我绝对不同意这个想法。我更喜欢锁不是

语言的一部分 - 使用适当的声明

锁定类型就是所需要的。


< snip>

读者/作者锁是非常常见的

我不记得上一次使用它了，我做了很多

多线程代码。通常情况下，您可以快速释放锁定

，只需使用正常状态即可。锁定比使用更重的ReaderWriterLock来使用
。在.NET 3.5中会有一个更小的RW-

锁，但即便如此，我也不会想要它的语言。

尽可能，语言应该（IMO）避免依赖于框架的
。有例外，但它们应该紧紧地控制。

此外，根据我的建议，不需要

创建一个读/写锁定对象并创建try finally块等。

语法更容易使用。

A使用声明很容易使用。

参见 http://pobox.com/~skeet/csharp/miscu...e/locking.html 对于

示例 - 可以轻松扩展以获得方法拿出一个

的ReaderWriter锁，或者有不同的类型可以适当地使用

。

如果这不是发布我的建议的正确位置，我在哪里发送我的

建议？

connections.microsoft.com是建议和错误

报告的正常位置。最好先对新闻组进行同行评审

，因此建议可以调整。提交之前。


Jon

5月31日上午9:50，Allan Ebdrup < ebd ... @ noemail.noemailwrote：


进一步思考：


< snip>
< blockquote class =post_quotes>
在幕后，第一次调用readlock（o）时，o上的锁定

机制将升级为读写器锁和任何活动状态，

排队或使用锁定（o）获得的未来锁定将成为作家

锁定。

您希望它如何运作？ C＃编译器仍然需要生成正常的b＃编译器。框架代码 - 如果这只是语法糖，

你能编写当前的C＃等价物，它会将一个线程中的锁

从简单的监视器锁升级到读取器/

a在另一个帖子中需要只读锁定吗？


Jon

肯定是*讨论它的有效地方，但是连接对于一个提案来说可能更好吗？但是这需要更多的工作......例如，
$ b b / b之间存在很大差异$ b ReaderWriterLock和Monitor（=锁定此刻）工作 - Monitor使用

目标对象的一部分，但ReaderWriterLock本身就是一个

对象。这两者根本不兼容。


显示器往往明显更轻量级，因此语法更改

这样就可以使用写入功能。 ReaderWriterLock将是一个巨大的变化 -

但这是你可能兼容的唯一方式

考虑re-entrancy，sub方法等。同样，这不会'支持

脉冲等


简而言之 - 我看不出它是可行的，在大多数情况下我不能

看到尝试的理由。在大多数情况下，Monitor绰绰有余。

在您确实需要并行并发访问的情况下，现有的ReaderWriterLock语法可以正常工作。我不记得

thewho或确切的报价，但一个很好的经验法则是：如果你想要这样的改变，那么最好是*更好*，否则

它不值得。在这种情况下，我不确定是不是。


IMHO


Marc

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

解决方案

On May 31, 9:50 am, "Allan Ebdrup" <[e-mail]:

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

On May 31, 9:50 am, "Allan Ebdrup" <[e-mail]:

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

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

这篇关于对C＃的建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！