On 7/9/07, Peter Ritchie
<[EMAIL PROTECTED]> wrote:
The Monitor.Exit generated by the lock statement has an implicit memory
barrier that will flush the CPU write cache at the end of the lock block.
You were right and I was wrong - somewhere (AwareLock::LeaveHelper
used by the SyncBlock implemen
A theme beaten practically to death in several different places.
You may want to check my series of posts on multithreading, a lot of ground
has been covered there.
http://www.delera.com/blog/?cat=2
(Although, on a second look, guys who post here seem to have gone 'wy
beyond the basics' and
Thank you, Peter - this is enough to give me stuff to research for the next
couple of days.
-Original Message-
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] Behalf Of Peter Ritchie
Sent: Monday, July 09, 2007 1:24 PM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re
is looking at a work in progress. For the DCBL pattern - if something
(compiler, processor, cache) is reordering write operations inside the lock,
there is a chance the cheating thread might think the singleton is fully
constructed even though all of the writes from the singleton's ctor have yet
t
Yes, a processor may be doing more than caching, so "flushing cached
writes" may be a bit simplistic in terms of what happens when
Thread.MemoryBarrier is called. But, it only deals with ensuring what the
processor may be doing, not with what the compiler is doing (or has done)
with registers. i.
Which can be made moot by declaring appropriate members "volatile".
I doubt the hyper-volatility Microsoft JITs would not add the memory
barrier at the exit of the constructor. But, it would be nice to know
what's it IS doing...
On Mon, 9 Jul 2007 10:57:27 -0700, Greg Young <[EMAIL PROTECTED]>
w
Peter Ritchie wrote:
>
> It's very clear with respect to CPU caching. Monitor.Enter is an
> implicit
> memory barrier, all CPU cached writes will be flushed to RAM (meant
> specifically for the object being locked; but most processors don't
> have
> that level of granularity so the whole cache is
The Monitor.Exit generated by the lock statement has an implicit memory
barrier that will flush the CPU write cache at the end of the lock block.
Adding a MemoryBarrier after the assignment to "instance" only guarantees
that cached writes up to that point are flushed to RAM. The only thing
visibl
Greg Young wrote:
> In the x86 JIT nearly EVERYTHING is considerred volatile, perhaps the
> others dont follow the spec?
I think the issue in the pre .NET 2.0 days was this: what happens when the
relaxed ECMA memory model meets a processor architecture with a relaxed
memory model (like the IA64 a
The more interesting question in all of this is that even with
completely safe code I cannot be assured by a conforming CLR that my
object is actually ready to be used on my other thread.
"It is explicitly not a requirement that a conforming implementation
of the CLI guarantee that all state upda
Fabian wrote:
>
> But isn't the point (and also the issue the barrier tries to solve)
> that code from outside the lock actually does access _provider in the
> double-checked locking pattern? So "nothing else can access provider
> while in the lock" seems not to be true, or is it?
>
Yes, I think
It seems the controversial point is whether such out-of-order writes
can occur with the .NET 2.0 memory model. Vance Morrison has written
an article [1] where he seems to say no (in this case), so volatile
(or explicit memory barrier) are not needed. Other sources (such as
the MSDN articles cited)
...not with MemoryBarrier within the synchronized block...
Hm, can you explain this a little more? If one adds a write barrier
after construction of the instance, but before assigning the instance
to the field, as Stoyan's original code did [1], doesn't this have the
desired effect of guaranteei
Hi Eddie, I haven't done it; but (if you want to use WebClient) I believe
you'll have to specialize WebClient and override the GetWebRequest
method. If you've got an http[s] URL, the default should create an
HttpWebRequest object (you'll have to cast from the WebRequest return from
the base, i.e.
Hi,
We have a problem with Korean language in .NET.
Scenario:
1. "Language for non-Unicode program" is set for Korean.
2. A text file download from host side, is displayed OK at pc for Korean
characters.
3. A .Net test project to read the file into a text box, and found it is
scrambled.
I think Greg associated my point to 335; but, specific to your question;
some sort of lock is necessary to block other threads from getting into
the static constructor in order to uphold that guarantee.
It's an implementation detail of the CLR wether using the implicit lock of
the static construct
Hello Peter,
You seem to be very experienced with these things so hopefully you can shed
some further light on this. In my case, the server requires a digital
certificate for access. I have installed that digital certificate on my
client, so when I try to access the resources (a folder) on the ser
Outside the lock block is a different story, yes. In which case you may
need something like:
Thread.MemoryBarrier(); // flush processor-cached writes.
if (provider_ == null)
{
lock (syncLock_)
{
if (provider_ == null)
{
I instance = Activator
pr
If provider_ is only set in that one place, or if it's set elsewhere and
within(syncLock_) you don't need the MemoryBarrier. Enter guarantees
acquire semantics and does the memory barrier for you (at the start of the
lock, and since nothing else can access provider while in the lock,
there's no n
With regard to compiler optimizations (C#-to-IL or IL-to-native, AKA JIT)
I don't think 335 is clear.
It's very clear with respect to CPU caching. Monitor.Enter is an implicit
memory barrier, all CPU cached writes will be flushed to RAM (meant
specifically for the object being locked; but most pr
On Mon, 9 Jul 2007 10:50:31 +0300, Stoyan Damov <[EMAIL PROTECTED]>
wrote:
>Yes, but your DCL is broken. However, if you rewrite it like this:
>
>if (provider_ == null)
>{
>lock (syncLock_)
>{
>if (provider_ == null)
>{
>I instance = Activator
>Th
This brings us to the interesting point, why is there disagreement?
This is a very clear statement that monitor is indeed a superset of
volatile.
Yes, it is. But AFAIK, the problem is that the non-volatile read at
the beginning of Ron's code might see the assigned _provider member
before the con
"Note that the MSDN patterns and practices article linked previously
[1] suggests to use the volatile keyword. It's from 2002, however, so
it's based on one of the 1.1 memory models. There is a second article
(without date, but it is more recent), which also suggests using
volatile [2]. I have als
Awesome.
-Original Message-
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Stoyan Damov
Sent: Monday, July 09, 2007 2:51 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] C# Singleton; foot in mouth
> protected static I Pro
Seems to me like you are looking for a depedecy injection framework like
windsor from the castle project.
Cheers,
Greg
On 7/9/07, Ron Young <[EMAIL PROTECTED]> wrote:
Further reference:
DownloadManager : BaseMangager
{
}
Problem is that the concept of "manager" should be allowed to work with
protected static I Provider
{
if (_provider == null)
{
lock (_syncLock)
{
if (provder = null)
provider =
Activator.createfromconfi
internal abstract class BaseManager where I: IEntityProvider
{
private static I _provider = default(I);
private static object _syncLock = new object();
protected static I Provider
{
if (_provider == null)
{
lock (_sy
27 matches
Mail list logo
