Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.programming.threads > #1163

Re: Memory barriers and ldrexd - race condition? (Desperate for an explanation!)

Show all headers | View raw

Toby Douglass wrote:
> Hi -
> 
> Can someone please please PLEASE help me understand something which is 
> still after a LOT of effort trying to understand confusing and puzzling 
> me.
> 
> I'm trying to get my head around memory barriers and load-
> link/conditional-store.
> 
> In the ARM Linux kernel, I see this function;
> 
> 353 static inline u64 atomic64_cmpxchg(atomic64_t *ptr, u64 old, u64 
> new)
> 354 {
> 355         u64 oldval;
> 356         unsigned long res;
> 357
> 358         smp_mb();
> 359
> 360         do {
> 361                 __asm__ __volatile__("@ atomic64_cmpxchg\n"
> 362                 "ldrexd         %1, %H1, [%3]\n"
> 363                 "mov            %0, #0\n"
> 364                 "teq            %1, %4\n"
> 365                 "teqeq          %H1, %H4\n"
> 366                 "strexdeq       %0, %5, %H5, [%3]"
> 367                 : "=&r" (res), "=&r" (oldval), "+Qo" (ptr->counter)
> 368                 : "r" (&ptr->counter), "r" (old), "r" (new)
> 369                 : "cc");
> 370         } while (res);
> 371
> 372         smp_mb();
> 373
> 374         return oldval;
> 375 }
> 
> Now, I recently read Paul McKenney's paper explaining the hardware 
> issues involved in memory barriers.
> 
> So what I understand is that the initial memory barrier flushes the 
> invalidate queue and the store buffer.
> 
> That's all good and well.
> 
> We then come to the ldrexd.  Now, this will perform the initial load and 
> activate the ERG covering the address where the load occurs.
> 
> (And then we compare and if the compare passes, we store.  We then issue 
> another memory barrier to ensure our store will be seen before any other 
> stores that we then perform (assuming the other CPUs issued read 
> barriers, of course)).
> 
> Now, that which I am so confused about; after the first memory barrier, 
> well - there's a period between the invalidate queue/store buffer flush 
> and the execution of ldrexd.
> 
> During this time another CPU (especially if we're running a lock-free 
> data structure, where we're using the same pointer a lot on different 
> CPUs) could issue an invalidate on that pointer - and we in our CPU 
> could fail to process it before executing ldrexd.
> 
> So we haven't yet activated the ERG - we're blind to the invalidate AND 
> we're about to load an out of date value from our cache!
> 
> So we can imagine doing so, doing the compare, the compare passes, and 
> then we store - which confuses me even more, because we could then store 
> and THEN find the invalidate...
> 
> So, I'm missing something here.  Question is, what?
> 
> PLEASE someone enlighten me!
> 
> It's that or insanity and I think I'm pretty close by now :-)

I think you could try posting in comp.arch (there are a few
concurrency experts over there).

Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Memory barriers and ldrexd - race condition? (Desperate for an explanation!) Toby Douglass <a@b.com> - 2012-10-02 23:58 +0200
  Re: Memory barriers and ldrexd - race condition? (Desperate for an explanation!) Noob <root@127.0.0.1> - 2012-10-03 13:20 +0200
    Re: Memory barriers and ldrexd - race condition? (Desperate for an explanation!) Toby Douglass <a@b.com> - 2012-10-03 13:22 +0200
  Re: Memory barriers and ldrexd - race condition? (Desperate for an explanation!) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-29 15:12 +0000
    Re: Memory barriers and ldrexd - race condition? (Desperate for an explanation!) Toby Douglass <a@b.com> - 2012-11-20 22:38 +0100
      Re: Memory barriers and ldrexd - race condition? (Desperate for an explanation!) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-21 04:34 +0000

csiph-web