Re: ATOMIC_* functions (again :)

From: Andrew Valencia <vandys_at_nospam.org>
Date: Sat Feb 11 1995 - 14:46:13 PST

[newsham@aloha.net (Timothy Newsham) writes:]

> I am looking over the new sources (vsta132) and noticed that the
>atomic increment and decrement functions are still not being used
>properly:

1.3.2, or the latest, 1.3.3?

> os/kern/
> port.c short (struct proc).p_nopen
> pset.c ushort (struct pset).p_refs

There are prototypes for the atomic functions now, so hopefully I can't have
strayed too far. p_nopen is a long, and is handled with the longword
version. p_refs is a short, and is handled with the short version.

> these two will have problems if long is 64 bits:
> malloc.c ulong
> xclock.c ulong (struct percpu).cp_ticks

I'm afraid I don't follow. The ATOMIC_INCL()/ATOMIC_DECL() have prototypes
for a longword argument. So you have to pass it a compatible (as defined by
ANSI C) type, which I *think* I do. malloc.c only uses these for n_alloc[],
which is a longword array. If longs become 64 bits, the array elements do,
too. The actual assembly code has to change, but that's to be expected if
you make such a fundamental change.

> os/mach
> several routines manipulate ushort (struct percpu).pc_locks

They all use ATOMIC_INCW/DECW, right?

>The routines themselves increment "long" (4 byte) quantities.
>I need these fixed for the amiga version.

I have a definite feeling you're not looking at the current code. Could you
download 1.3.3 from ftp.cisco.com:vandys/vsta and double check?

>I was using ATOMIC_INCW/DECW() and ATOMIC_INCL/DECL() in my
>original code. Let me know what you will be using so I
>can keep my code consistent with the main tree.

From include/sys/mutex.h:

extern void ATOMIC_INCW(volatile ushort *);
extern void ATOMIC_DECW(volatile ushort *);
extern void ATOMIC_INCL(volatile ulong *);
extern void ATOMIC_DECL(volatile ulong *);
extern void ATOMIC_INC(volatile uint *);
extern void ATOMIC_DEC(volatile uint *);

I guess I should have warned you what release I folded your comments into.
Sorry for the confusion!

                                                Andy
Received on Sat Feb 11 14:08:41 1995

This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:17 PDT