Suggestion: Dynamic __compare_and_swap() behaviour in SMP/non-SMP machines

["Tal Davidson" <tal at givenimaging dot com>]

Hi all,

I hope I am finally in the correct mailing list for this...

As of linuxthreads version 2.2.5, and as of the current CVS, I
understand that the "__compare_and_exchange" for Intel x86 processors
(in linuxthresds/sysdeps/i386/pt-machine.c), used for locking various
synchronization objects, contains the following assembly, in which a
"lock;" assembly command is always hard-coded regardless of whether the
computer is SMP or not.                           
   __asm__ __volatile__ ( "lock; cmpxchgl %3, %1; sete %0"
			: "=q" (ret), "=m" (*p), "=a" (readval)
			: "r" (newval), "m" (*p), "a" (oldval)
			: "memory");

The "lock;" assembly command is unneeded on single processor (non-SMP)
workstations, and SEVERELY slows down the behavior of various pthread
synchronization objects.

On my single Pentium IV processor Linux Redhat 7.3 machine, I compared
the raising and lowering speeds of various pthreads synchronization
objects with and without the "lock" assembly command. Using the
benchmark codes in Dr. Ed Bradford's article on my modified version of
pt-machine.c, I have found that pthread mutex locking/unlocking and
semaphore waiting/posting performed continuously on a single thread to
be running around 3 TIMES FASTER without the "lock;" assembly command in
the above code as compared to original "__compare_and_exchange"
implementation. Using the same benchmark on a Windows 2000, I found
recursive pthread mutexes to now run as fast as Win32 critical sections
when without the "lock' assembly in the above code.

Two proper methods for removing the "lock" are of course static removal
(using the pre-compiler), and dynamic removal (using dynamic testing if
the system running is indeed SMP or not).

Since linuxthreads checks dynamically for a SMP kernel using
"is_smp_system()" in the pthread initiation code (in the pthread_init
method), and since this information is then stored in the
"__pthread_smp_kernel" global variable, 
what are your thoughts on the following patch
for"linuxthreads/sysdeps/i386/pt-machine.h", in which a dynamic decision
is made whether to use "lock; cmpxchg" in SMP systems and only "cmpxchg"
assembly in non-SMP systems?

extern int __pthread_smp_kernel;


PT_EI int
__compare_and_swap (long int *p, long int oldval, long int newval)
{
  char ret;
  long int readval;

  if (__pthread_smp_kernel)
  {
   __asm__ __volatile__ ( "lock; cmpxchgl %3, %1; sete %0"
			: "=q" (ret), "=m" (*p), "=a" (readval)
			: "r" (newval), "m" (*p), "a" (oldval)
			: "memory");
  }
  else
  {
   __asm__ __volatile__ ( "cmpxchgl %3, %1; sete %0"
			: "=q" (ret), "=m" (*p), "=a" (readval)
			: "r" (newval), "m" (*p), "a" (oldval)
			: "memory");
  }

  return ret;
}


Using the same benchmarks, I have found this code with dynamic testing
of SMP to be only 4% slower than a static test, and as discussed above,
300% faster in various catching and releasing of pthreads mutexes and
semaphores.

What do you think?

Thanks,
Tal Davidson





----------------------------Email Disclaimer---------------------------
The following refers to email messages transmitted from,
or on behalf of Given Imaging. The information contained 
in this e-mail and it's attached files, including replies 
and forwarded copies, is confidential and intended solely 
for the addressee(s) and may be legally privileged or 
prohibited from disclosure and unauthorized use. If you 
are not the named addressee you may not use, copy or 
disclose this information to any other person. If you 
received this message in error please notify the sender 
immediately and delete all copies of the email and it's
associated files. If you are not the intended recipient, 
any form of reproduction, dissemination, copying, disclosure, 
modification, distribution and/or publication or any action 
taken or omitted to be taken in reliance upon this message 
or its attachments is prohibited and may be unlawful.

Any views or opinions presented are solely those of the 
originator and do not necessarily represent those of Given Imaging. 
All liability for viruses is excluded to the fullest extent permitted by law.
--------------------------------EOD------------------------------------