RE: Atomic operations

RE: Atomic operations

[Gregory Giguashvili]

Peter,

Thanks a lot for your help. 

> atomic_t test_then_add (int i, atomic_t* v)
> {
>    atomic_t old = *v;
>    v->counter += i;
>    return old;
> }
> There is no way to do this (without waiting and trying again type
> code) that I know of on i386.  However, you can test for zeroness of
> the result, or for <= 0, or a few other options.

Could you, please, clarify what you meant saying that there was no way of
doing so. I admit, I'm no expert in i386 assembly, but this operation seems
so simple to me...

Could you, please, suggest some other implementation (with waiting and
trying again - whatever this means)?

test_and_set and test_then_add functions are coming from code written for
IRIX. Solaris has similar functionality. Windows NT also provides these
primitives in Win32 API (possibly implemented not in the most effective way,
according to what you say). The only OS where they are missing is Linux. 

Unfortunately, these primitives became an integral part of our code, which
makes it very painful to change their behavior.

Thanks in advance.
Giga

Re: Atomic operations

[H. Peter Anvin]

Followup to:  <EE83E551E08D1D43AD52D50B9F5110927E7A15@ntserver2>
By author:    Gregory Giguashvili <Gregoryg@ParadigmGeo.com>
In newsgroup: linux.dev.kernel
> 
> Could you, please, clarify what you meant saying that there was no way of
> doing so. I admit, I'm no expert in i386 assembly, but this operation seems
> so simple to me...
> 

That doesn't mean the hardware is going to provide it atomically.

> 
> Could you, please, suggest some other implementation (with waiting and
> trying again - whatever this means)?
> 

Very simple:

- Set a spinlock (note: you need a spinlock variable)
- Read
- Add
- Clear spinlock

This is called "bootstrapping" -- using a more primitive atomic
operation to get what you need.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

atomic operations

[Shraddha Kamat]

what is the relation between atomic operations and memory alignment ?

I read from UTLK that "an unaligned memory access is not atomic" 

please explain me , I am not able to get the relationship between 
memory alignment and atomicity of the operation.

atomic operations

[richard -rw- weinberger]

On Sun, Feb 24, 2013 at 10:42 AM, Shraddha Kamat <sh2008ka@gmail.com> wrote:
> what is the relation between atomic operations and memory alignment ?
>
> I read from UTLK that "an unaligned memory access is not atomic"
>
> please explain me , I am not able to get the relationship between
> memory alignment and atomicity of the operation.

Not all CPUs support unaligned memory access, such an access may cause a fault
which needs to be fixed by the kernel...

-- 
Thanks,
//richard

atomic operations

[Valdis.Kletnieks at vt.edu]

On Sun, 24 Feb 2013 11:50:14 +0100, richard -rw- weinberger said:
> On Sun, Feb 24, 2013 at 10:42 AM, Shraddha Kamat <sh2008ka@gmail.com> wrote:
> > what is the relation between atomic operations and memory alignment ?
> >
> > I read from UTLK that "an unaligned memory access is not atomic"
> >
> > please explain me , I am not able to get the relationship between
> > memory alignment and atomicity of the operation.
>
> Not all CPUs support unaligned memory access, such an access may cause a fault
> which needs to be fixed by the kernel...

There's a more subtle issue - an unaligned access can be split across a cache
line boundary, requiring 2 separate memory accesses to do the read or write.
This can result in CPU A fetching the first half of the variable, CPU B
updating both halves, and then A fetching the second half of the now updated
variable.. This can bite you even on CPUs that support unaligned accesses.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130224/d2bc34b0/attachment.bin 

atomic operations

[Peter Teoh]

in simple terms, any operation, in terms assembly instructions, which can
be executed in ONE instruction, is "atomic", because, just like an atom, it
cannot be broken up into parts.   any instructions that is longer than one,
for eg, TWO instruction, is NOT atomic, because in BETWEEN the first and
2nd instruction, something like an interrupt can come in, and affect the
values of the operand when it is passed from instruction one to second
instruction.  To save me from reiteration:

http://www.ibm.com/developerworks/library/pa-dalign/ (search for
"atomicity").

http://stackoverflow.com/questions/381244/purpose-of-memory-alignment

http://lwn.net/Articles/260832/

http://www.songho.ca/misc/alignment/dataalign.html

http://www.cis.upenn.edu/~palsetia/cit595s08/Lectures08/alignmentOrdering.pdf

Essentially, atomicity and non-alignment become problematic when u tried to
to read using non-byte addressing mode with non-aligned address.

On Sun, Feb 24, 2013 at 5:42 PM, Shraddha Kamat <sh2008ka@gmail.com> wrote:

> what is the relation between atomic operations and memory alignment ?
>
> I read from UTLK that "an unaligned memory access is not atomic"
>
> please explain me , I am not able to get the relationship between
> memory alignment and atomicity of the operation.
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 
Regards,
Peter Teoh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130224/36c27526/attachment.html 

atomic operations

[Peter Teoh]

Another good article on atomicty and data sizes:

http://www.ibm.com/developerworks/library/pa-atom/

On Sun, Feb 24, 2013 at 8:50 PM, Peter Teoh <htmldeveloper@gmail.com> wrote:

> in simple terms, any operation, in terms assembly instructions, which can
> be executed in ONE instruction, is "atomic", because, just like an atom, it
> cannot be broken up into parts.   any instructions that is longer than one,
> for eg, TWO instruction, is NOT atomic, because in BETWEEN the first and
> 2nd instruction, something like an interrupt can come in, and affect the
> values of the operand when it is passed from instruction one to second
> instruction.  To save me from reiteration:
>
> http://www.ibm.com/developerworks/library/pa-dalign/ (search for
> "atomicity").
>
> http://stackoverflow.com/questions/381244/purpose-of-memory-alignment
>
> http://lwn.net/Articles/260832/
>
> http://www.songho.ca/misc/alignment/dataalign.html
>
>
> http://www.cis.upenn.edu/~palsetia/cit595s08/Lectures08/alignmentOrdering.pdf
>
> Essentially, atomicity and non-alignment become problematic when u tried
> to to read using non-byte addressing mode with non-aligned address.
>
> On Sun, Feb 24, 2013 at 5:42 PM, Shraddha Kamat <sh2008ka@gmail.com>wrote:
>
>> what is the relation between atomic operations and memory alignment ?
>>
>> I read from UTLK that "an unaligned memory access is not atomic"
>>
>> please explain me , I am not able to get the relationship between
>> memory alignment and atomicity of the operation.
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
>
>
> --
> Regards,
> Peter Teoh
>



-- 
Regards,
Peter Teoh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130224/c982b31a/attachment.html 

atomic operations

[Kumar amit mehta]

On Sun, Feb 24, 2013 at 08:53:20PM +0800, Peter Teoh wrote:
> Another good article on atomicty and data sizes:
> 
> http://www.ibm.com/developerworks/library/pa-atom/
> 
> On Sun, Feb 24, 2013 at 8:50 PM, Peter Teoh <htmldeveloper@gmail.com> wrote:
> 
> > in simple terms, any operation, in terms assembly instructions, which can
> > be executed in ONE instruction, is "atomic", because, just like an atom, it
> > cannot be broken up into parts.   any instructions that is longer than one,
> > for eg, TWO instruction, is NOT atomic, because in BETWEEN the first and
> > 2nd instruction, something like an interrupt can come in, and affect the
> > values of the operand when it is passed from instruction one to second
> > instruction.  To save me from reiteration:
> >
> > http://www.ibm.com/developerworks/library/pa-dalign/ (search for
> > "atomicity").
> >
> > http://stackoverflow.com/questions/381244/purpose-of-memory-alignment
> >
> > http://lwn.net/Articles/260832/
> >
> > http://www.songho.ca/misc/alignment/dataalign.html
> >
> >
> > http://www.cis.upenn.edu/~palsetia/cit595s08/Lectures08/alignmentOrdering.pdf
> >
> > Essentially, atomicity and non-alignment become problematic when u tried
> > to to read using non-byte addressing mode with non-aligned address.
> >
> > On Sun, Feb 24, 2013 at 5:42 PM, Shraddha Kamat <sh2008ka@gmail.com>wrote:
> >
> >> what is the relation between atomic operations and memory alignment ?
> >>
> >> I read from UTLK that "an unaligned memory access is not atomic"
> >>
> >> please explain me , I am not able to get the relationship between
> >> memory alignment and atomicity of the operation.
It seems for this same reason, every objects of a struct page is organized as 
double word.
<snip from linux/mm_types.h>
 * The objects in struct page are organized in double word blocks in
 * order to allows us to use atomic double word operations on portions
 * of struct page. That is currently only used by slub but the arrangement
 * allows the use of atomic double word operations on the flags/mapping
 * and lru list pointers also.
<snip from linux/mm_types.h>

-Amit

atomic operations

[Arun KS]

Hi Peter,

On Sun, Feb 24, 2013 at 6:20 PM, Peter Teoh <htmldeveloper@gmail.com> wrote:
> in simple terms, any operation, in terms assembly instructions, which can be
> executed in ONE instruction, is "atomic", because, just like an atom, it
> cannot be broken up into parts.   any instructions that is longer than one,
> for eg, TWO instruction, is NOT atomic, because in BETWEEN the first and 2nd
> instruction, something like an interrupt can come in, and affect the values
> of the operand when it is passed from instruction one to second instruction.

Nice explanation.

Thanks,
Arun
> To save me from reiteration:
>
> http://www.ibm.com/developerworks/library/pa-dalign/ (search for
> "atomicity").
>
> http://stackoverflow.com/questions/381244/purpose-of-memory-alignment
>
> http://lwn.net/Articles/260832/
>
> http://www.songho.ca/misc/alignment/dataalign.html
>
> http://www.cis.upenn.edu/~palsetia/cit595s08/Lectures08/alignmentOrdering.pdf
>
> Essentially, atomicity and non-alignment become problematic when u tried to
> to read using non-byte addressing mode with non-aligned address.
>
> On Sun, Feb 24, 2013 at 5:42 PM, Shraddha Kamat <sh2008ka@gmail.com> wrote:
>>
>> what is the relation between atomic operations and memory alignment ?
>>
>> I read from UTLK that "an unaligned memory access is not atomic"
>>
>> please explain me , I am not able to get the relationship between
>> memory alignment and atomicity of the operation.
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
>
> --
> Regards,
> Peter Teoh
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

Atomic operations

[Timothy Hayes]

[-- Attachment #1.1: Type: text/plain, Size: 1206 bytes --]

I'm sure a lot of you know XenSocket (XVMSocket), if not, it's a Loadable
Kernel Module with a socket interface that sends/receives to/from a shared
page of memory mapped between two domains. It's quite a nice idea and brings
data throughput close to UNIX sockets. I made some changes and made it
compatible with Xen 3.2 and a newer Linux kernel (I'm testing it with
2.6.25.20) however I'm noticing some odd behaviour occasionally. In it,
there are atomic_t variables in a descriptor inside a shared memory page.
When a domain sends or receives from the socket, it will use one of the
atomic_ operations to update the amount of new data available. The problem
I'm noticing is that when two domains are concurrently updating this
variable, the value becomes inconsistent leading me to believe that the
atomic_ operations might not guarantee atomicity between domains. I haven't
been able to repeat any behaviour like this when I limit the two guests to
the same physical CPU and eliminate parallelism.

Would anyone be able fill me in if I'm missing something? Are the atomic_
operations 100% foolproof for this sort of thing? If not, what would be the
best approach to use instead?

Kind regards
Tim Hayes

[-- Attachment #1.2: Type: text/html, Size: 1260 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Atomic operations

[Keir Fraser]

[-- Attachment #1.1: Type: text/plain, Size: 1358 bytes --]

The Linux atomic.h operations will be atomic even across domains.

 -- Keir

On 26/03/2009 00:17, "Timothy Hayes" <hayesti@tcd.ie> wrote:

> I'm sure a lot of you know XenSocket (XVMSocket), if not, it's a Loadable
> Kernel Module with a socket interface that sends/receives to/from a shared
> page of memory mapped between two domains. It's quite a nice idea and brings
> data throughput close to UNIX sockets. I made some changes and made it
> compatible with Xen 3.2 and a newer Linux kernel (I'm testing it with
> 2.6.25.20) however I'm noticing some odd behaviour occasionally. In it, there
> are atomic_t variables in a descriptor inside a shared memory page. When a
> domain sends or receives from the socket, it will use one of the atomic_
> operations to update the amount of new data available. The problem I'm
> noticing is that when two domains are concurrently updating this variable, the
> value becomes inconsistent leading me to believe that the atomic_ operations
> might not guarantee atomicity between domains. I haven't been able to repeat
> any behaviour like this when I limit the two guests to the same physical CPU
> and eliminate parallelism.
> 
> Would anyone be able fill me in if I'm missing something? Are the atomic_
> operations 100% foolproof for this sort of thing? If not, what would be the
> best approach to use instead?


[-- Attachment #1.2: Type: text/html, Size: 1728 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Atomic operations

[Juergen Gross]

Keir Fraser wrote:
> The Linux atomic.h operations will be atomic even across domains.

... unless CONFIG_SMP was not defined in the domU kernel build.


Juergen

> On 26/03/2009 00:17, "Timothy Hayes" <hayesti@tcd.ie> wrote:
> 
>     I'm sure a lot of you know XenSocket (XVMSocket), if not, it's a
>     Loadable Kernel Module with a socket interface that sends/receives
>     to/from a shared page of memory mapped between two domains. It's
>     quite a nice idea and brings data throughput close to UNIX sockets.
>     I made some changes and made it compatible with Xen 3.2 and a newer
>     Linux kernel (I'm testing it with 2.6.25.20) however I'm noticing
>     some odd behaviour occasionally. In it, there are atomic_t variables
>     in a descriptor inside a shared memory page. When a domain sends or
>     receives from the socket, it will use one of the atomic_ operations
>     to update the amount of new data available. The problem I'm noticing
>     is that when two domains are concurrently updating this variable,
>     the value becomes inconsistent leading me to believe that the
>     atomic_ operations might not guarantee atomicity between domains. I
>     haven't been able to repeat any behaviour like this when I limit the
>     two guests to the same physical CPU and eliminate parallelism.
> 
>     Would anyone be able fill me in if I'm missing something? Are the
>     atomic_ operations 100% foolproof for this sort of thing? If not,
>     what would be the best approach to use instead?
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


-- 
Juergen Gross                             Principal Developer
IP SW OS6                      Telephone: +49 (0) 89 636 47950
Fujitsu Siemens Computers         e-mail: juergen.gross@fujitsu-siemens.com
Otto-Hahn-Ring 6                Internet: www.fujitsu-siemens.com
D-81739 Muenchen         Company details: www.fujitsu-siemens.com/imprint.html

Re: Atomic operations

[Keir Fraser]

On 26/03/2009 07:34, "Juergen Gross" <juergen.gross@fujitsu-siemens.com>
wrote:

> Keir Fraser wrote:
>> The Linux atomic.h operations will be atomic even across domains.
> 
> ... unless CONFIG_SMP was not defined in the domU kernel build.

Yes, good point. Actually I assumed the OP was copying atomic.h for his own
use, but he probably isn't actually. And either way the CONFIG_SMP ifdef'ery
could bite.

 -- Keir

Re: Atomic operations

[Timothy Hayes]

[-- Attachment #1.1: Type: text/plain, Size: 948 bytes --]

My domU kernels are configured with:

CONFIG_SMP=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
# CONFIG_X86_PC is not set
CONFIG_X86_XEN=y

The problem occurs when I limit the VCPUs in each guest to 1, presumably
they get scheduled into unique physical CPUs in parallel. Is there anything
else I should be aware of? I'm quite optimistic that the XenSocket logic is
sound, the only thing I can attribute this to is a lack of atomicity.

Tim

2009/3/26 Keir Fraser <keir.fraser@eu.citrix.com>

> On 26/03/2009 07:34, "Juergen Gross" <juergen.gross@fujitsu-siemens.com>
> wrote:
>
> > Keir Fraser wrote:
> >> The Linux atomic.h operations will be atomic even across domains.
> >
> > ... unless CONFIG_SMP was not defined in the domU kernel build.
>
> Yes, good point. Actually I assumed the OP was copying atomic.h for his own
> use, but he probably isn't actually. And either way the CONFIG_SMP
> ifdef'ery
> could bite.
>
>  -- Keir
>
>
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 1448 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Atomic operations

[Keir Fraser]

The problem is that we dynamically remove LOCK_PREFIX when the guest has
only one vcpu. You need your own version of atomic.h in which you do not use
LOCK_PREFIX but use Œlock¹ directly instead. See
include/asm-i386/mach-xen/asm/sync_bitops.h for example, which is our
guaranteed inter-domain safe version of bitops.h.

 -- Keir

On 27/03/2009 17:22, "Timothy Hayes" <hayesti@tcd.ie> wrote:

> CONFIG_SMP=y
> CONFIG_X86_FIND_SMP_CONFIG=y
> CONFIG_X86_MPPARSE=y
> # CONFIG_X86_PC is not set
> CONFIG_X86_XEN=y
> 
> The problem occurs when I limit the VCPUs in each guest to 1, presumably they
> get scheduled into unique physical CPUs in parallel. Is there anything else I
> should be aware of? I'm quite optimistic that the XenSocket logic is sound,
> the only thing I can attribute this to is a lack of atomicity.

Re: Atomic operations

[Timothy Hayes]

[-- Attachment #1.1: Type: text/plain, Size: 1201 bytes --]

Ah, that did the trick! I couldn't really see why that was happening since
CONFIG_SMP was defined in my environment so I had no reason to suspect that
the LOCK_PREFIX was being removed. In any case, it's running without hiccups
now. Cheers

Tim

2009/3/27 Keir Fraser <keir.fraser@eu.citrix.com>

> The problem is that we dynamically remove LOCK_PREFIX when the guest has
> only one vcpu. You need your own version of atomic.h in which you do not
> use
> LOCK_PREFIX but use Œlock¹ directly instead. See
> include/asm-i386/mach-xen/asm/sync_bitops.h for example, which is our
> guaranteed inter-domain safe version of bitops.h.
>
>  -- Keir
>
> On 27/03/2009 17:22, "Timothy Hayes" <hayesti@tcd.ie> wrote:
>
> > CONFIG_SMP=y
> > CONFIG_X86_FIND_SMP_CONFIG=y
> > CONFIG_X86_MPPARSE=y
> > # CONFIG_X86_PC is not set
> > CONFIG_X86_XEN=y
> >
> > The problem occurs when I limit the VCPUs in each guest to 1, presumably
> they
> > get scheduled into unique physical CPUs in parallel. Is there anything
> else I
> > should be aware of? I'm quite optimistic that the XenSocket logic is
> sound,
> > the only thing I can attribute this to is a lack of atomicity.
>
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 1674 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: Atomic operations

[Gregory Giguashvili]

Hello,

Thanks a lot for your help to all of you...

The last thing, I want to make sure of, is that the following type of code:

int atomic_xadd(int i, atomic_t *v)
{
	int ret;
	__asm__(LOCK "xaddl %1,%0"
		: "=m" (v->counter), "=r" (ret)
		: "0" (v->counter), "1" (i));
	return ret;
}

is less efficient than this one:

int atomic_xadd(int i, atomic_t *v)
{
	asm volatile(LOCK "xaddl %1,%0"
		: "+m" (v->counter), "+r" (i));
	return i;
}

The reason for it is that the first one is more easy to read (at least for
me as a beginner). 

Thanks again for your precious comments.
Best,
Giga

Atomic operations

[Gregory Giguashvili]

Hello,

I forgot to add that I know that it can be implemented using XCHG and LOCK
operations. However, I'm not an expert in ASM, so I was hoping somebody
would help me...

Thanks 
Giga

Atomic operations

[Gregory Giguashvili]

Hello,

I wonder if someone can help me to change the behaviour of the atomic
functions available in <asm/atomic.h> include file. The operations I need to
implement are described below:

atomic_t test_and_set (int i, atomic_t* v)
{
   atomic_t old = *v;
   v->counter = i;
   return old;
}

atomic_t test_then_add (int i, atomic_t* v)
{
   atomic_t old = *v;
   v->counter += i;
   return old;
}

Thanks in advance,
Giga

Re: Atomic operations

[H. Peter Anvin]

Followup to:  <EE83E551E08D1D43AD52D50B9F5110927E7A10@ntserver2>
By author:    Gregory Giguashvili <Gregoryg@ParadigmGeo.com>
In newsgroup: linux.dev.kernel
>
> Hello,
> 
> I wonder if someone can help me to change the behaviour of the atomic
> functions available in <asm/atomic.h> include file. The operations I need to
> implement are described below:
> 
> atomic_t test_and_set (int i, atomic_t* v)
> {
>    atomic_t old = *v;
>    v->counter = i;
>    return old;
> }
> 

This is not a test and set operation.

On i386:

atomic_t atomic_exchange (atomic_t i, atomic_t *v)
{
   asm volatile("xchgl %0,%1" : "+m" (*v), "+r" (i));
   return i;
}

> atomic_t test_then_add (int i, atomic_t* v)
> {
>    atomic_t old = *v;
>    v->counter += i;
>    return old;
> }

There is no way to do this (without waiting and trying again type
code) that I know of on i386.  However, you can test for zeroness of
the result, or for <= 0, or a few other options.

int test_and_add (atomic_t i, atomic_t *v)
{
  char was_nonzero;	/* MUST BE CHAR!!! */

  asm volatile("lock; addl %2,%0; setz %1"
    : "+m" (*v), "=rm" (was_nonzero)
    : "g" (i));

  return was_nonzero;
}

  

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: Atomic operations

[Richard B. Johnson]

On Mon, 3 Jun 2002, Gregory Giguashvili wrote:

> Hello,
> 
> I wonder if someone can help me to change the behaviour of the atomic
> functions available in <asm/atomic.h> include file. The operations I need to
> implement are described below:
> 
> atomic_t test_and_set (int i, atomic_t* v)
> {
>    atomic_t old = *v;
>    v->counter = i;
>    return old;
> }
>

atomic_t test_and_set(int i, atomic_t *v)
{
    int ret;

    __asm__ __volatile__(LOCK "movl (%1), %ecx\n"
                         LOCK "orl   %0,  (%1)\n" 
	: ecx (ret) 
	: "r" (i), "m" (v)
	: "ecx", "memory" );

    return (ret & i);
}

I did not check this to even see if it compiles. It serves only
as an example of a problem with your requirements. You may be
able to use BTS for your problem, but that may not satisfy your
requirements.

In the above example, I lock the bus and move the contents of
your memory location into a register. Then, I lock the bus again
and OR in the bits you require. Later, I see if that bit was set
in the return value. Unfortunately, a lot can change during the
two lock instructions.

To use the BTS instruction, you do something like this:

atomic_t test_and_set(int i, atomic_t *v)
{
    int ret;
    __asm__ __volatile__("xorl %ecx, %ecx\n"
                         LOCK "btsl %0, (%1)\n"
                         "adcl %ecx, ecx\n"
	: ecx (ret) 
	: "r" (i), "m" (v)
	: "ecx", "memory" );

    return(i && ret);  /* Note Logical AND */
// or
    return ret; 
}
 
BTS will test a bit then set it. The result of the initial
test will be in the CY flag. I zero a register first, do the stuff,
then add the contents of the CY flag into the previously-zeroed
register. This I how I return the result. Again, this may not
be what you want although you may be able to modify the logic of
your code to accept such.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: Atomic operations

[Thunder from the hill]

Hi,

On Mon, 3 Jun 2002, Richard B. Johnson wrote:
> atomic_t test_and_set(int i, atomic_t *v)
> {
>     int ret;
> 
>     __asm__ __volatile__(LOCK "movl (%1), %ecx\n"
>                          LOCK "orl   %0,  (%1)\n" 
> 	: ecx (ret) 
> 	: "r" (i), "m" (v)
> 	: "ecx", "memory" );
> 
>     return (ret & i);
> }

I'm not an expert, but shouldn't "exc" be quoted here? I'm just 
wondering...

Regards,
Thunder
-- 
ship is leaving right on time	|	Thunder from the hill at ngforever
empty harbour, wave goodbye	|
evacuation of the isle		|	free inhabitant not directly
caveman's paintings drowning	|	belonging anywhere

Re: Atomic operations

[Richard B. Johnson]

On Mon, 3 Jun 2002, Thunder from the hill wrote:

> Hi,
> 
> On Mon, 3 Jun 2002, Richard B. Johnson wrote:
> > atomic_t test_and_set(int i, atomic_t *v)
> > {
> >     int ret;
> > 
> >     __asm__ __volatile__(LOCK "movl (%1), %ecx\n"
> >                          LOCK "orl   %0,  (%1)\n" 
> > 	: "ecx" (ret) 
> > 	: "r" (i), "m" (v)
> > 	: "ecx", "memory" );
> > 
> >     return (ret & i);
> > }
> 
> I'm not an expert, but shouldn't "exc" be quoted here? I'm just 
                                    ecx 
                           Yes, we both make typos!
> wondering...



Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: Atomic operations

[Brian Gerst]

Gregory Giguashvili wrote:
> 
> Hello,
> 
> I wonder if someone can help me to change the behaviour of the atomic
> functions available in <asm/atomic.h> include file. The operations I need to
> implement are described below:
> 
> atomic_t test_and_set (int i, atomic_t* v)
> {
>    atomic_t old = *v;
>    v->counter = i;
>    return old;
> }

What you have coded is really an exchange, not a test.  Here is the asm
equivalent of what you coded:

int atomic_xchg(int i, atomic_t *v)
{
	int ret;
	__asm__("xchgl %1,%0"
		: "=m" (v->counter), "=r" (ret)
		: "0" (v->counter), "1" (i));
	return ret;
}

> 
> atomic_t test_then_add (int i, atomic_t* v)
> {
>    atomic_t old = *v;
>    v->counter += i;
>    return old;
> }

int atomic_xadd(int i, atomic_t *v)
{
	int ret;
	__asm__(LOCK "xaddl %1,%0"
		: "=m" (v->counter), "=r" (ret)
		: "0" (v->counter), "1" (i));
	return ret;
}

This one only works on 486+, but there are practically no real 386 SMP
systems.

--

				Brian Gerst

Re: Atomic operations

[H. Peter Anvin]

Followup to:  <3CFBB7DB.831BE453@didntduck.org>
By author:    Brian Gerst <bgerst@didntduck.org>
In newsgroup: linux.dev.kernel
> 
> int atomic_xadd(int i, atomic_t *v)
> {
> 	int ret;
> 	__asm__(LOCK "xaddl %1,%0"
> 		: "=m" (v->counter), "=r" (ret)
> 		: "0" (v->counter), "1" (i));
> 	return ret;
> }
> 
> This one only works on 486+, but there are practically no real 386 SMP
> systems.
> 

<slaps forehead>

Boy do I feel dumb now.

The only nitpick is that it's probably better coded as:

int atomic_xadd(int i, atomic_t *v)
{
	asm volatile(LOCK "xaddl %1,%0"
		: "+m" (v->counter), "+r" (i));
	return i;
}
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>