Groups > comp.lang.c++ > #88265 > unrolled thread

Christmas Quiz...

Started by	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
First post	2022-12-26 13:22 -0800
Last post	2023-01-17 18:25 -0800
Articles	14 — 4 participants

Back to article view | Back to comp.lang.c++

  Christmas Quiz... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-26 13:22 -0800
    Re: Christmas Quiz... "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-12-26 23:17 +0100
    Re: Christmas Quiz... Bonita Montero <Bonita.Montero@gmail.com> - 2022-12-27 04:59 +0100
      Re: Christmas Quiz... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-27 13:29 -0800
      Re: Christmas Quiz... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-04 00:40 -0800
        Re: Christmas Quiz... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-04 00:41 -0800
    Re: Christmas Quiz... Michael S <already5chosen@yahoo.com> - 2022-12-27 03:38 -0800
    Re: Christmas Quiz... Michael S <already5chosen@yahoo.com> - 2022-12-27 03:42 -0800
      Re: Christmas Quiz... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-27 13:31 -0800
        Re: Christmas Quiz... Michael S <already5chosen@yahoo.com> - 2022-12-27 14:09 -0800
          Re: Christmas Quiz... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-27 14:17 -0800
            Re: Christmas Quiz... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-29 20:42 -0800
    Re: Christmas Quiz... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-04 00:38 -0800
    Re: Christmas Quiz... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-17 18:25 -0800

#88265 — Christmas Quiz...

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2022-12-26 13:22 -0800
Subject	Christmas Quiz...
Message-ID	<tod3b8$3c8u8$4@dont-email.me>

Imagine you are on a SPARC in RMO mode, you are programming in assembly 
language. What memory barrier instruction is the most efficient _and_ 
correct for use _after_ using an atomic RMW instruction to take 
exclusive access? Think about locking a mutex...

A: MEMBAR #LoadLoad

B: MEMBAR #LoadStore | #LoadLoad

C: MEMBAR #StoreLoad | #LoadLoad

D: MEMBAR #StoreLoad | #StoreStore


What about the membar we have to use before atomically unlocking this mutex?


A: MEMBAR #LoadLoad

B: MEMBAR #StoreLoad | #LoadLoad

C: MEMBAR #LoadStore | #StoreStore

D: MEMBAR #StoreLoad | #StoreStore

[toc] | [next] | [standalone]

#88266

From	"Alf P. Steinbach" <alf.p.steinbach@gmail.com>
Date	2022-12-26 23:17 +0100
Message-ID	<tod6ha$3crah$1@dont-email.me>
In reply to	#88265

On 26 Dec 2022 22:22, Chris M. Thomasson wrote:
> Imagine you are on a SPARC in RMO mode, you are programming in assembly 
> language. What memory barrier instruction is the most efficient _and_ 
> correct for use _after_ using an atomic RMW instruction to take 
> exclusive access? Think about locking a mutex...
> 
> A: MEMBAR #LoadLoad
> 
> B: MEMBAR #LoadStore | #LoadLoad
> 
> C: MEMBAR #StoreLoad | #LoadLoad
> 
> D: MEMBAR #StoreLoad | #StoreStore
> 
> 
> What about the membar we have to use before atomically unlocking this 
> mutex?
> 
> 
> A: MEMBAR #LoadLoad
> 
> B: MEMBAR #StoreLoad | #LoadLoad
> 
> C: MEMBAR #LoadStore | #StoreStore
> 
> D: MEMBAR #StoreLoad | #StoreStore

I really don't have the foggiest idea, but I wish I had! :-o

Google tells me that "RMO mode" is relaxed memory order, and I remember 
that's been mentioned in what I've read about C++ threading.

I can understand that being relevant, but "a SPARC"?

Anyway, best wishes for the coming new year.

Hopefully at the end there will be less war, less crisis, everything 
better except the climate (which is FUBAR), and with everything better 
we can be happy no matter what the climate does. Except my old fav idea 
of saving the polar bears by transporting them to Antarctica, because 
the penguins -- possible Antarctica food source -- are now an endangered 
species. But, better.

- Alf

[toc] | [prev] | [next] | [standalone]

#88267

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2022-12-27 04:59 +0100
Message-ID	<todqib$3hkat$3@dont-email.me>
In reply to	#88265

Am 26.12.2022 um 22:22 schrieb Chris M. Thomasson:
> Imagine you are on a SPARC in RMO mode, you are programming in assembly 
> language. What memory barrier instruction is the most efficient _and_ 
> correct for use _after_ using an atomic RMW instruction to take 
> exclusive access? Think about locking a mutex...
> 
> A: MEMBAR #LoadLoad
> 
> B: MEMBAR #LoadStore | #LoadLoad
> 
> C: MEMBAR #StoreLoad | #LoadLoad
> 
> D: MEMBAR #StoreLoad | #StoreStore
> 
> 
> What about the membar we have to use before atomically unlocking this 
> mutex?
> 
> 
> A: MEMBAR #LoadLoad
> 
> B: MEMBAR #StoreLoad | #LoadLoad
> 
> C: MEMBAR #LoadStore | #StoreStore
> 
> D: MEMBAR #StoreLoad | #StoreStore

1. I use proper C++ barriers so I won't have to care for that.
2. SPARC  is dead.

[toc] | [prev] | [next] | [standalone]

#88272

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2022-12-27 13:29 -0800
Message-ID	<tofo3e$3nhm2$2@dont-email.me>
In reply to	#88267

On 12/26/2022 7:59 PM, Bonita Montero wrote:
> Am 26.12.2022 um 22:22 schrieb Chris M. Thomasson:
>> Imagine you are on a SPARC in RMO mode, you are programming in 
>> assembly language. What memory barrier instruction is the most 
>> efficient _and_ correct for use _after_ using an atomic RMW 
>> instruction to take exclusive access? Think about locking a mutex...
>>
>> A: MEMBAR #LoadLoad
>>
>> B: MEMBAR #LoadStore | #LoadLoad
>>
>> C: MEMBAR #StoreLoad | #LoadLoad
>>
>> D: MEMBAR #StoreLoad | #StoreStore
>>
>>
>> What about the membar we have to use before atomically unlocking this 
>> mutex?
>>
>>
>> A: MEMBAR #LoadLoad
>>
>> B: MEMBAR #StoreLoad | #LoadLoad
>>
>> C: MEMBAR #LoadStore | #StoreStore
>>
>> D: MEMBAR #StoreLoad | #StoreStore
> 
> 1. I use proper C++ barriers so I won't have to care for that.
> 2. SPARC  is dead.
> 

Well, suppose you were tasked with creating the guts for C++ membars for 
the SPARC. Imvvho, the SPARC in RMO mode is a good place to learn. The 
MEMBAR instruction is pretty damn diverse! :^)

[toc] | [prev] | [next] | [standalone]

#88389

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2023-01-04 00:40 -0800
Message-ID	<tp3e1c$2dmo3$9@dont-email.me>
In reply to	#88267

On 12/26/2022 7:59 PM, Bonita Montero wrote:
> Am 26.12.2022 um 22:22 schrieb Chris M. Thomasson:
>> Imagine you are on a SPARC in RMO mode, you are programming in 
>> assembly language. What memory barrier instruction is the most 
>> efficient _and_ correct for use _after_ using an atomic RMW 
>> instruction to take exclusive access? Think about locking a mutex...
>>
>> A: MEMBAR #LoadLoad
>>
>> B: MEMBAR #LoadStore | #LoadLoad
>>
>> C: MEMBAR #StoreLoad | #LoadLoad
>>
>> D: MEMBAR #StoreLoad | #StoreStore
>>
>>
>> What about the membar we have to use before atomically unlocking this 
>> mutex?
>>
>>
>> A: MEMBAR #LoadLoad
>>
>> B: MEMBAR #StoreLoad | #LoadLoad
>>
>> C: MEMBAR #LoadStore | #StoreStore
>>
>> D: MEMBAR #StoreLoad | #StoreStore
> 
> 1. I use proper C++ barriers so I won't have to care for that.
> 2. SPARC  is dead.
> 

What are the proper C++ barriers then?

[toc] | [prev] | [next] | [standalone]

#88390

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2023-01-04 00:41 -0800
Message-ID	<tp3e46$2e2oe$3@dont-email.me>
In reply to	#88389

On 1/4/2023 12:40 AM, Chris M. Thomasson wrote:
> On 12/26/2022 7:59 PM, Bonita Montero wrote:
>> Am 26.12.2022 um 22:22 schrieb Chris M. Thomasson:
>>> Imagine you are on a SPARC in RMO mode, you are programming in 
>>> assembly language. What memory barrier instruction is the most 
>>> efficient _and_ correct for use _after_ using an atomic RMW 
>>> instruction to take exclusive access? Think about locking a mutex...
>>>
>>> A: MEMBAR #LoadLoad
>>>
>>> B: MEMBAR #LoadStore | #LoadLoad
>>>
>>> C: MEMBAR #StoreLoad | #LoadLoad
>>>
>>> D: MEMBAR #StoreLoad | #StoreStore
>>>
>>>
>>> What about the membar we have to use before atomically unlocking this 
>>> mutex?
>>>
>>>
>>> A: MEMBAR #LoadLoad
>>>
>>> B: MEMBAR #StoreLoad | #LoadLoad
>>>
>>> C: MEMBAR #LoadStore | #StoreStore
>>>
>>> D: MEMBAR #StoreLoad | #StoreStore
>>
>> 1. I use proper C++ barriers so I won't have to care for that.
>> 2. SPARC  is dead.
>>
> 
> What are the proper C++ barriers then?

Too easy? Well, how to you implement them on a weakly ordered system? A 
SPARC in RMO mode is a good place to start.

[toc] | [prev] | [next] | [standalone]

#88270

From	Michael S <already5chosen@yahoo.com>
Date	2022-12-27 03:38 -0800
Message-ID	<677c0843-8df4-4618-b6ad-59560102c0c9n@googlegroups.com>
In reply to	#88265

On Monday, December 26, 2022 at 11:23:06 PM UTC+2, Chris M. Thomasson wrote:
> Imagine you are on a SPARC in RMO mode, you are programming in assembly 
> language. What memory barrier instruction is the most efficient _and_ 
> correct for use _after_ using an atomic RMW instruction to take 
> exclusive access? Think about locking a mutex... 
> 
> A: MEMBAR #LoadLoad 
> 
> B: MEMBAR #LoadStore | #LoadLoad 
> 
> C: MEMBAR #StoreLoad | #LoadLoad 
> 
> D: MEMBAR #StoreLoad | #StoreStore 
> 
> 
> What about the membar we have to use before atomically unlocking this mutex? 
> 
> 
> A: MEMBAR #LoadLoad 
> 
> B: MEMBAR #StoreLoad | #LoadLoad 
> 
> C: MEMBAR #LoadStore | #StoreStore 
> 
> D: MEMBAR #StoreLoad | #StoreStore

[toc] | [prev] | [next] | [standalone]

#88271

From	Michael S <already5chosen@yahoo.com>
Date	2022-12-27 03:42 -0800
Message-ID	<cd552208-e199-4e50-9ec5-d0c3f9d7eeeen@googlegroups.com>
In reply to	#88265

On Monday, December 26, 2022 at 11:23:06 PM UTC+2, Chris M. Thomasson wrote:
> Imagine you are on a SPARC in RMO mode, you are programming in assembly 
> language. 

If I am not mistaken, SPARC RMO is paper spec that was never implemented
in hardware. Which does not mean that it is impossible to imagine that I am
programming it in assembler, but it takes stronger imagination than I posses.

> What memory barrier instruction is the most efficient _and_ 
> correct for use _after_ using an atomic RMW instruction to take 
> exclusive access? Think about locking a mutex... 
> 
> A: MEMBAR #LoadLoad 
> 
> B: MEMBAR #LoadStore | #LoadLoad 
> 
> C: MEMBAR #StoreLoad | #LoadLoad 
> 
> D: MEMBAR #StoreLoad | #StoreStore 
> 
> 
> What about the membar we have to use before atomically unlocking this mutex? 
> 
> 
> A: MEMBAR #LoadLoad 
> 
> B: MEMBAR #StoreLoad | #LoadLoad 
> 
> C: MEMBAR #LoadStore | #StoreStore 
> 
> D: MEMBAR #StoreLoad | #StoreStore

[toc] | [prev] | [next] | [standalone]

#88273

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2022-12-27 13:31 -0800
Message-ID	<tofo74$3nhm2$3@dont-email.me>
In reply to	#88271

On 12/27/2022 3:42 AM, Michael S wrote:
> On Monday, December 26, 2022 at 11:23:06 PM UTC+2, Chris M. Thomasson wrote:
>> Imagine you are on a SPARC in RMO mode, you are programming in assembly
>> language.
> 
> If I am not mistaken, SPARC RMO is paper spec that was never implemented
> in hardware. Which does not mean that it is impossible to imagine that I am
> programming it in assembler, but it takes stronger imagination than I posses.

SPARC RMO is a real thing.

https://www.linuxjournal.com/article/8212

"Solaris on SPARC uses total-store order (TSO); however, Linux runs 
SPARC in relaxed-memory order (RMO) mode."


> 
>> What memory barrier instruction is the most efficient _and_
>> correct for use _after_ using an atomic RMW instruction to take
>> exclusive access? Think about locking a mutex...
>>
>> A: MEMBAR #LoadLoad
>>
>> B: MEMBAR #LoadStore | #LoadLoad
>>
>> C: MEMBAR #StoreLoad | #LoadLoad
>>
>> D: MEMBAR #StoreLoad | #StoreStore
>>
>>
>> What about the membar we have to use before atomically unlocking this mutex?
>>
>>
>> A: MEMBAR #LoadLoad
>>
>> B: MEMBAR #StoreLoad | #LoadLoad
>>
>> C: MEMBAR #LoadStore | #StoreStore
>>
>> D: MEMBAR #StoreLoad | #StoreStore

[toc] | [prev] | [next] | [standalone]

#88275

From	Michael S <already5chosen@yahoo.com>
Date	2022-12-27 14:09 -0800
Message-ID	<86aee34d-0c60-4c16-a75c-2615f4138238n@googlegroups.com>
In reply to	#88273

On Tuesday, December 27, 2022 at 11:31:33 PM UTC+2, Chris M. Thomasson wrote:
> On 12/27/2022 3:42 AM, Michael S wrote: 
> > On Monday, December 26, 2022 at 11:23:06 PM UTC+2, Chris M. Thomasson wrote: 
> >> Imagine you are on a SPARC in RMO mode, you are programming in assembly 
> >> language. 
> > 
> > If I am not mistaken, SPARC RMO is paper spec that was never implemented 
> > in hardware. Which does not mean that it is impossible to imagine that I am 
> > programming it in assembler, but it takes stronger imagination than I posses.
> SPARC RMO is a real thing. 
> 
> https://www.linuxjournal.com/article/8212 
> 
> "Solaris on SPARC uses total-store order (TSO); however, Linux runs 
> SPARC in relaxed-memory order (RMO) mode."

I am pretty sure that the article got it wrong.
OS can set control bits in register to any value it wishes, but the underlying
hardware will still behave as TSO.
At least, if the hardware is made by Sun/Oracle or Fujitsu, but all other SPARC
CPU vendors became irrelevant since ~1996, anyway.

> > 
> >> What memory barrier instruction is the most efficient _and_ 
> >> correct for use _after_ using an atomic RMW instruction to take 
> >> exclusive access? Think about locking a mutex... 
> >> 
> >> A: MEMBAR #LoadLoad 
> >> 
> >> B: MEMBAR #LoadStore | #LoadLoad 
> >> 
> >> C: MEMBAR #StoreLoad | #LoadLoad 
> >> 
> >> D: MEMBAR #StoreLoad | #StoreStore 
> >> 
> >> 
> >> What about the membar we have to use before atomically unlocking this mutex? 
> >> 
> >> 
> >> A: MEMBAR #LoadLoad 
> >> 
> >> B: MEMBAR #StoreLoad | #LoadLoad 
> >> 
> >> C: MEMBAR #LoadStore | #StoreStore 
> >> 
> >> D: MEMBAR #StoreLoad | #StoreStore

[toc] | [prev] | [next] | [standalone]

#88276

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2022-12-27 14:17 -0800
Message-ID	<tofqtk$3nhm2$5@dont-email.me>
In reply to	#88275

On 12/27/2022 2:09 PM, Michael S wrote:
> On Tuesday, December 27, 2022 at 11:31:33 PM UTC+2, Chris M. Thomasson wrote:
>> On 12/27/2022 3:42 AM, Michael S wrote:
>>> On Monday, December 26, 2022 at 11:23:06 PM UTC+2, Chris M. Thomasson wrote:
>>>> Imagine you are on a SPARC in RMO mode, you are programming in assembly
>>>> language.
>>>
>>> If I am not mistaken, SPARC RMO is paper spec that was never implemented
>>> in hardware. Which does not mean that it is impossible to imagine that I am
>>> programming it in assembler, but it takes stronger imagination than I posses.
>> SPARC RMO is a real thing.
>>
>> https://www.linuxjournal.com/article/8212
>>
>> "Solaris on SPARC uses total-store order (TSO); however, Linux runs
>> SPARC in relaxed-memory order (RMO) mode."
> 
> I am pretty sure that the article got it wrong.
> OS can set control bits in register to any value it wishes, but the underlying
> hardware will still behave as TSO.
> At least, if the hardware is made by Sun/Oracle or Fujitsu, but all other SPARC
> CPU vendors became irrelevant since ~1996, anyway.
[...]

Are you telling me that SPARC RMO mode was run as if it was TSO in the 
hardware? I need to ask Paul.

[toc] | [prev] | [next] | [standalone]

#88304

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2022-12-29 20:42 -0800
Message-ID	<tolq85$iu8p$3@dont-email.me>
In reply to	#88276

On 12/27/2022 2:17 PM, Chris M. Thomasson wrote:
> On 12/27/2022 2:09 PM, Michael S wrote:
>> On Tuesday, December 27, 2022 at 11:31:33 PM UTC+2, Chris M. Thomasson 
>> wrote:
>>> On 12/27/2022 3:42 AM, Michael S wrote:
>>>> On Monday, December 26, 2022 at 11:23:06 PM UTC+2, Chris M. 
>>>> Thomasson wrote:
>>>>> Imagine you are on a SPARC in RMO mode, you are programming in 
>>>>> assembly
>>>>> language.
>>>>
>>>> If I am not mistaken, SPARC RMO is paper spec that was never 
>>>> implemented
>>>> in hardware. Which does not mean that it is impossible to imagine 
>>>> that I am
>>>> programming it in assembler, but it takes stronger imagination than 
>>>> I posses.
>>> SPARC RMO is a real thing.
>>>
>>> https://www.linuxjournal.com/article/8212
>>>
>>> "Solaris on SPARC uses total-store order (TSO); however, Linux runs
>>> SPARC in relaxed-memory order (RMO) mode."
>>
>> I am pretty sure that the article got it wrong.
>> OS can set control bits in register to any value it wishes, but the 
>> underlying
>> hardware will still behave as TSO.
>> At least, if the hardware is made by Sun/Oracle or Fujitsu, but all 
>> other SPARC
>> CPU vendors became irrelevant since ~1996, anyway.
> [...]
> 
> Are you telling me that SPARC RMO mode was run as if it was TSO in the 
> hardware? I need to ask Paul.
> 

This is a big deal because an atomic store in TSO implies release 
barrier semanitcs, just like x86. One can release a spinlock in x86 with 
an atomic store, no explicit membar needed. sparc in rmo mode does not 
have implied release wrt atomic stores.

[toc] | [prev] | [next] | [standalone]

#88388

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2023-01-04 00:38 -0800
Message-ID	<tp3du0$2dmo3$8@dont-email.me>
In reply to	#88265

On 12/26/2022 1:22 PM, Chris M. Thomasson wrote:
> Imagine you are on a SPARC in RMO mode, you are programming in assembly 
> language. What memory barrier instruction is the most efficient _and_ 
> correct for use _after_ using an atomic RMW instruction to take 
> exclusive access? Think about locking a mutex...
> 
> A: MEMBAR #LoadLoad
> 
> B: MEMBAR #LoadStore | #LoadLoad
> 
> C: MEMBAR #StoreLoad | #LoadLoad
> 
> D: MEMBAR #StoreLoad | #StoreStore
> 
> 
> What about the membar we have to use before atomically unlocking this 
> mutex?
> 
> 
> A: MEMBAR #LoadLoad
> 
> B: MEMBAR #StoreLoad | #LoadLoad
> 
> C: MEMBAR #LoadStore | #StoreStore
> 
> D: MEMBAR #StoreLoad | #StoreStore

A hint. A mutex does not need #StoreLoad ordering.

[toc] | [prev] | [next] | [standalone]

#88584

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2023-01-17 18:25 -0800
Message-ID	<tq7lb5$3fv85$1@dont-email.me>
In reply to	#88265

On 12/26/2022 1:22 PM, Chris M. Thomasson wrote:
> Imagine you are on a SPARC in RMO mode, you are programming in assembly 
> language. What memory barrier instruction is the most efficient _and_ 
> correct for use _after_ using an atomic RMW instruction to take 
> exclusive access? Think about locking a mutex...
> 
> A: MEMBAR #LoadLoad
> 
> B: MEMBAR #LoadStore | #LoadLoad
> 
> C: MEMBAR #StoreLoad | #LoadLoad
> 
> D: MEMBAR #StoreLoad | #StoreStore
> 
> 
> What about the membar we have to use before atomically unlocking this 
> mutex?
> 
> 
> A: MEMBAR #LoadLoad
> 
> B: MEMBAR #StoreLoad | #LoadLoad
> 
> C: MEMBAR #LoadStore | #StoreStore
> 
> D: MEMBAR #StoreLoad | #StoreStore


Get the answer by clicking on the following link. The password is membar:

http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=b77c814baf6376631199bcdf0a0e763136fceb0f56dd238dba943d05e54a47451c63e2fe25ca4b6b8b9dfaba2fd22dccf20261ad63a409ce2384cb734804bcbb068edcd3a7ae6bf91ba7d88e8c27a82b4c973f7421020e43

Just a test of my HMAC cipher... ;^)

[toc] | [prev] | [standalone]

csiph-web

Christmas Quiz...

Contents

#88265 — Christmas Quiz...

#88266

#88267

#88272

#88389

#88390

#88270

#88271

#88273

#88275

#88276

#88304

#88388

#88584