Re: atomic_ question
On 2001-Feb-08 18:21:07 +0100, Bernd Walter [EMAIL PROTECTED] wrote: Are atomic_* implementations allowed to spin/sleep? The atomic_* operations are the primitives used to build all the higher level locking functions. Therefore you are not allowed to sleep. As for spinning: You can't implement them using a `normal' spinlock. Some architectures, eg the Alpha, don't have RMW primitives. The Alpha has load-locked and store-conditional instructions which let you build atomic operations - you need to spin between the load and store if the store fails. The store will only fail if you took an interrupt between the load and store or if another master updated the location between your load and store. Look into /sys/alpha/alpha/atomic.s for code. The only way to implement them on these platforms is to use a lock. Except that locks are built using the atomic_* functions. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: atomic_ question
On Fri, Feb 09, 2001 at 07:57:50AM +1100, Peter Jeremy wrote: On 2001-Feb-08 18:21:07 +0100, Bernd Walter [EMAIL PROTECTED] wrote: Are atomic_* implementations allowed to spin/sleep? The atomic_* operations are the primitives used to build all the higher level locking functions. Therefore you are not allowed to sleep. As for spinning: You can't implement them using a `normal' spinlock. Some architectures, eg the Alpha, don't have RMW primitives. The Alpha has load-locked and store-conditional instructions which let you build atomic operations - you need to spin between the load and store if the store fails. The store will only fail if you took an interrupt between the load and store or if another master updated the location between your load and store. Look into /sys/alpha/alpha/atomic.s for code. The alpha way of doing it is very similar to sparcv9. But the alpha code and the code neccesary for sparcv9 has a difference compared to normal spinning. If you get interrupted the interupt code can modify the same value without getting blocked while the interrupted code simply needs another cycle. On sparcv8 you don't have an operation doing conditionaly stores and you don't have RMW operations. The only way to do is to have a global lock variable on which you spin until the current client finishes. That means you can't use them in interrupt code! I saw that some implementations for atomic code for sparcv8 disables interrupts before fetching the lock to suround this problem. Do we grant usuage of the atomic functions in interrupt code? If yes there is a need to disable interrupts! I'm not talking about interrupt threads. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: atomic_ question
On 08-Feb-01 Bernd Walter wrote: Do we grant usuage of the atomic functions in interrupt code? If yes there is a need to disable interrupts! I'm not talking about interrupt threads. Yes, we use spin mutexes to schedule ithreads, and we use other atomic operations in IPI handlers. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: atomic_ question
On 2001-Feb-08 22:21:32 +0100, Bernd Walter [EMAIL PROTECTED] wrote: On sparcv8 you don't have an operation doing conditionaly stores and you don't have RMW operations. The only way to do is to have a global lock variable on which you spin until the current client finishes. The SPARC architecture supports SMP so there must be some synchronisation primitive that works between processors (disabling interrupts only works on the current processor). Normally the same primitive can be used to synchronise accesses within the same processor. I know the older SPARC's had a test-and-set instruction which was locked RMW - there must be something similar in v8 and v9. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: atomic_ question
On Fri, Feb 09, 2001 at 11:00:04AM +1100, Peter Jeremy wrote: On 2001-Feb-08 22:21:32 +0100, Bernd Walter [EMAIL PROTECTED] wrote: On sparcv8 you don't have an operation doing conditionaly stores and you don't have RMW operations. The only way to do is to have a global lock variable on which you spin until the current client finishes. The SPARC architecture supports SMP so there must be some synchronisation primitive that works between processors (disabling interrupts only works on the current processor). Normally the same primitive can be used to synchronise accesses within the same processor. I know the older SPARC's had a test-and-set instruction which was locked RMW - there must be something similar in v8 and v9. sparcv8 has: LDSTUB - which is a atomic load into register and store 0xff SWAP - which exchanges a register with memory atomicly sparcv9 has additionaly the Comapare And Set (CAS) operation which makes it similar in use as alpha. I can't speak for sparcv7 and older but maybe you are refering to sparcv9 with it's CAS operation as an "older" SPARC or have a vendor specific extension in mind. Disabling interrupts will work fine because the reason is to avoid deadlocks. The only thing needed is that the processor holding the lock can't be interrupted until it's finished. If another CPU want's the same lock it can spinwait because the other CPU still gets the chance to release the lock. No doubt the available primitives are enough - but I wanted to know if its neccessary to go the complete ugly way. The sparv8 way for FreeBSDs atomic_ is now clear to me: disable ints for the CPU in question fetch the lock do the real work wmb unlock restore ints Thank you all for making this clear. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: atomic_ question
* Bernd Walter [EMAIL PROTECTED] [010208 09:21] wrote: Are atomic_* implementations allowed to spin/sleep? The question is because some platforms don't have atomic operations for adding and so on (e.g. sparcv8). Actually, you can use atomic_* on sparc, but you're limited to 24 bits. The only way to implement them on these platforms is to use a lock. Now I'm wonder if the use of a sleep mutex is allowed or is a simple spinning lock the sensefull choice. Either one would work. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
