Folks,

On the spin lock and multiple CPU's, this should not be
a compile time issue, but a runtime issue. What do you 
think?

Jordan Henderson


Sun, 15 Feb 1998 21:05:09 -0500
Jordan Henderson <jordanh@ccia.com>
Re: [HACKERS] spin locks
On Sun, 15 Feb 1998, Jordan Henderson wrote:

> Folks,
> 
> On the spin lock and multiple CPU's, this should not be
> a compile time issue, but a runtime issue. What do you 
> think?

	And you are proposing...?

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Sun, 15 Feb 1998 22:18:59 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] spin locks
Folks,

On the thread in regards to spinlocks and multiple CPU's.
The line of thought appeared to be select a compile
time option to determine behavior, and whether to yield or not.

I am thinking that if it comes to having alternate code, the
system should be able to make the determination at runtime,
not compile time. I don't know if all of the platforms supported
have a version of the sysinfo utility, but here is how, at runtime
it gets the number of CPUS available:

**** EXCERPTED FROM SYSINFO SOURCE 3.3.1 ****
/*
 * Use sysconf() to find number of CPU's.
 */
extern char *GetNumCpuSysconf()
{
    int				Num = -1;
    static char		       *NumStr = NULL;

    if (NumStr)
	return(NumStr);

#if	defined(_SC_NPROCESSORS_CONF)
    Num = (int) sysconf(_SC_NPROCESSORS_CONF);
    if (Num >= 0) {
	NumStr = itoa(Num);
	if (NumStr)
	    NumStr = strdup(NumStr);
    }
#endif	/* _SC_NPROCESSORS_CONF */

    return(NumStr);
}

What I would propose, if the decision is made to yield,
that at initialization time, the number of CPU's available
are determined, and a flag set, or, an indirect jump
changed. This would allow the software to have both
personalities, depending on which system it found it
self running on.

Thoughts?
Jordan Henderson


Mon, 16 Feb 1998 09:21:34 -0500
Jordan Henderson <jordanh@ccia.com>
Re: [HACKERS] spin locks
> 
> Folks,
> 
> On the spin lock and multiple CPU's, this should not be
> a compile time issue, but a runtime issue. What do you 
> think?
> 
> Jordan Henderson
> 
> 
> 

Yes.

-- 
Bruce Momjian
maillist@candle.pha.pa.us

Mon, 16 Feb 1998 15:50:52 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] spin locks
> 
> > 
> > Folks,
> > 
> > On the spin lock and multiple CPU's, this should not be
> > a compile time issue, but a runtime issue. What do you 
> > think?
> > 
> > Jordan Henderson
> > 
> > 
> > 
> 
> Yes.

Yes, if we have the tprintf patch we can also add an option flag and change
it un the fly while the backends are running.

-- 
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto                e-mail:  dz@cs.unitn.it            |
|  Via Marconi, 141                 phone:  ++39-461-534251            |
|  38057 Pergine Valsugana (TN)     www:  http://www.cs.unitn.it/~dz/  |
|  Italy                            pgp:  finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+


Mon, 16 Feb 1998 23:33:00 +0100 (MET)
Massimo Dal Zotto <dz@cs.unitn.it>
Re: [HACKERS] spin locks