[Mono-devel-list] Double-locking and thread safety

[Kornél Pál]

> From: Ben Maurer
> Anyways, there is no use arguing about this stuff. If you can show that
> more complex code results in a measurable speedup, feel free to bring it
> up ;-).

Although the current code is not complex lock, MemoryBarrier and
CompareExchange could be invoked a hundreds of times but to get proper
results they should be executed on the right architecture (multi-processor
system, threads on different processors, probably on IA64). I think it's
difficult to make a managed thread to use a specific processor and
MemoryBarrier is not implemented at all by Mono so it cannot be tested. And
of course the runtime does not support IA64. I don't want to argue about
this because it seems to be nearly impossible to test it.:)

But you can make sure that creating a new instance requires more time than
waiting for another thread to create it because:
1. We can assume that creating an object requires the same time because
alhough it's slower to create the first instance (static constructors, file
loading from disk, ...) the second thread has to wait these static
constructors so the second instance cannot be created faster.
2. Usually one of the threads start to create the instance earlier so one of
them will be created earlier.
3. Thus one of the threads will create the instance while all the other
threads will not create their instance before the first thread.
4. Usually the other threads will finish later so it's wasting of time.

And doing this has no drawbacks because if all of the threads finish the
same time only one of them did usefull work and all the others were wasting
CPU cycles so it sill has the advantage of CPU cycles.

This theoritically seems to be better than doing the reverse.

> In the meanwhile, I've done a few data-collection things:
>
> [benm at omega ~]$ mono --trace=T:Locale install/lib/monodoc/browser.exe
> ENTER: Locale:GetText (string)([STRING:0x42720:EST], )
> LEAVE: Locale:GetText (string)[STRING:0x42720:EST]
> ENTER: Locale:GetText (string)([STRING:0x42738:EDT], )
> LEAVE: Locale:GetText (string)[STRING:0x42738:EDT]
>
> (this is after browsing about for a bit).
>
> So, it looks like it is possible the people using DateTime will
> experience a bit of slowness. However, I wonder if for this specific
> case, we can rely on the OS's database of time zones.

You were right I did not know or used these tools.

Note that these strings are localized by the TimeZone class rather than
DateTime.

I don't know whether they should be localized but it is a bad practicle to
localize names in the constructor. They should be localized when the string
is returned because you can use different CurrentUICultures to retrive them
than you used to create the class.

> On mcs, there were *no* calls to Locale.GetText except when I tried to
> compile a non-existent file. In that case, the exception was caught,
> however it was still localized. Can this be avoided?

No. The problem is that the message (and not a key or format pattern) has to
be passed to the constructor of Exception. As MS.NET uses keys they have to
pass the localized message thus the message will be in the language used to
throw the Exception. This should be done by Mono to preserve compatibility.
Furthermore the message cannot contain any parameters ({0}, {1}, ...) it has
to contain a message with parameters filled in. And as applications can use
any messages (that may be localized by themselves) and probably they don't
want the class library to localize their messages.

> As for the expense of the reflection stuff you used, I have this test
> case:
>
>
>> using System;
>> using System.Text;
>>
>> class X {
>>         static void Main ()
>>         {
>>                 Console.WriteLine ("X");
>>                 //Console.WriteLine (typeof (X).Assembly.GetName
>> ().Name);
>>         }
>> }
>

My only problem is that I don't know how much penalty does this mean (I
don't know how to interpret the results).

I don't insist on using this code if you have a better solution please let
me know.

Kornél