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

[Ben Maurer]

On Thu, 2005-06-23 at 19:49 +0200, Kornél Pál wrote:
> >> 2. Removing the check outside the lock would solve the problem but it
> >> results in performance loss because of memory barriers for each read.
> >
> > The real problem is that the lock can result in contention which is
> > orders of magnitude worse than a memory barrier.
> 
> You are right, but memory barriers should be done by lock as well so it's
> very inefficient.

As I said, the lock is MUCH more expensive than the barrier ;-).

> It's sufficient but I can't understand why not to use a more sufficient
> solution if we already know that solution.

Because our interests are (in order):

     1. Correct code
     2. Code that is not noticeably slow to the user
     3. Readable/Maintainable/Clear code
     4. Micro-tuned code

Your stuff falls under 4.

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 ;-).

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.

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?


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);
>         }
> }

I first did stats with the C.WL alone, and then with reflection:

[benm at omega ~]$ mono --stats foo.exe
X
Mono Jit statistics
Compiled methods:       149
Methods from AOT:       0
Methods cache lookup:   97
Method trampolines:     1529
Basic blocks:           964
Max basic blocks:       48
Allocated vars:         707
Analyze stack repeat:   0
Compiled CIL code size: 7665
Native code size:       15188
Max code size ratio:    6.00 (TextWriter::Synchronized)
Biggest method:         1726 (UTF8Encoding::InternalGetBytes)
Code reallocs:          1
Allocated code size:    15188
Inlineable methods:     0
Inlined methods:        4

Created object count:   236
Initialized classes:    144
Used classes:           65
Static data size:       188
VTable data size:       7916


[benm at omega ~]$ mono --stats foo.exe
foo
Mono Jit statistics
Compiled methods:       190
Methods from AOT:       0
Methods cache lookup:   161
Method trampolines:     1973
Basic blocks:           1211
Max basic blocks:       48
Allocated vars:         918
Analyze stack repeat:   0
Compiled CIL code size: 10557
Native code size:       20097
Max code size ratio:    6.00 (TextWriter::Synchronized)
Biggest method:         1726 (UTF8Encoding::InternalGetBytes)
Code reallocs:          1
Allocated code size:    20097
Inlineable methods:     0
Inlined methods:        4

Created object count:   380
Initialized classes:    167
Used classes:           79
Static data size:       256
VTable data size:       9500

-- Ben