26419 - PR_Lock() is slow on NT

Status: RESOLVED INVALID

(NSPR :: NSPR, defect, P3)

Description

[troy]

On NT PR_EnterMonitor() calls PR_Lock() which calls EnterCriticalSection(). I 
was told by someone on NSPR (I think) that Microsoft's runtime implements a fast 
version of the call, but looking at the Quantify runs that doesn't seem to be 
the case

What I see in my Quantify run is the call going to the kernel. Can't we have 
NSPR use the JS locks that are very fast?

Here are the first few lines from the Quantify run that show 
EnterCriticalSection() as the number two most expensive call taking up 10.16% of 
the time

new	30485	128630.18	162632.39	11.33	14.32	4.22	1.64	
3769.86	C:\WINNT\System32\MSVCRT.DLL	(None)	Timed	Yes
EnterCriticalSection	55108	115407.43	115407.43	10.16	10.16	
2.09	0.00	62843.43	C:\WINNT\System32\KERNEL32.DLL	(None)	Sys 
Block	No
memcpy	99482	101924.81	101924.81	8.98	8.98	1.02	0.00	
5300.55	C:\WINNT\System32\MSVCRT.DLL	(None)	Timed	No
nsRenderingContextWin::GetWidth	7852	37526.32	89409.75	3.30	
7.87	4.78	2.92	523.29	d:\mozilla\dist\win32_o.obj\bin\GKGFXWIN.DLL	
(None)	Timed	No
malloc	7410	35838.94	47523.81	3.16	4.18	4.83	1.56	
5757.18	C:\WINNT\System32\MSVCRT.DLL	(None)	Timed	No
nsRenderingContextWin::SetFont	3887	35365.67	51515.32	3.11	
4.54	9.10	3.77	2530.43	d:\mozilla\dist\win32_o.obj\bin\GKGFXWIN.DLL	
(None)	Timed	No
PostMessageA	241	34696.33	34696.33	3.06	3.06	143.97	
0.02	15345.53	C:\WINNT\System32\USER32.DLL	(None)	System	Yes

Comment 1

[srinivas]

EnterCriticalSection makes a kernel call only when there is lock contention. 
When there is no contention, EnterCriticalSection runs in user-mode and is 
efficient.

You can look at the Bugzilla report #20357 for a comparison of the "thin JS 
locks" and NSPR locks. There was also a "Thin Locks?" thread of posts in the 
mozilla.nspr newsgroup.

Comment 2

[srinivas]

Is this still an unresolved issue or should this bug be marked invalid?

Comment 3

[troy]

I think it's resolved. I'm marking INVALID