tempesta-tech / blog Goto Github PK

Hi Krizhanovsky, thank you for your such good job about transactional memory, I run the code tsx.cc, but I'm very confused that why conflicts happen in the case of independent location? in these lines https://github.com/natsys/blog/blob/master/tsx.cc#L153-L158, when overlap is zero, each thread access their own data location, I think it's not need to lock the data by spin lock way. and no conflicts will happen by tsx way?

Hi @krizhanovsky

Thank you for your nice work.

Here is my two question harassing my brain,

• what does the // Force compiler to use tmp_h exactly once. mean? Need here a compiler barrier?
• Should memory barrier be inserted before thr_pos().head = ULONG_MAX; and thr_pos().tail = ULONG_MAX;, after the specified element read / written?

Can you add license text to some of the examples? Currently, it's unclear as to what their licenses are.

last_head_ and last_tail_ are not marked as volatile in lockfree_rb_q.cc. Per the article in http://www.linuxjournal.com/content/lock-free-multi-producer-multi-consumer-queue-ring-buffer?page=0,3, doesnt it need to be marked volatile ? Or does builtin_expect automagically force the compile to load last_head_ and last_tail_ from memory everytime ?

If it is not volatile, it seems like it will be a bug.

Please forgive me if I'm missing something here...

in lockfree_rb_q.cc class LockFreeQueue, there appear to be two issues related to ulong overflow (wrap around).

1. the ULONG_MAX "parking value" is not excluded from reservation, nor from "min" testing. the "invalid" value can't ever be used as a valid value, nor compared with them

2. the comparison for min testing will be incorrect if the span of thread specific head and tail values crosses overflow

There appear to be two choice -- compared the signed distance, If the max difference is representable in long, will give the correct comparison (if the difference isn't, then one push of pop isn't making forward progress... or you have more than 2 billion threads)

( 0 < long(min - tmp_[ht})

Slightly more robust (it could handle a ULONG_MAXth old pending request :) ) would be comparing the head - tail values -- guaranteed to be positive and correctly comparable -, though eventually a hung push or pop operation would stall all operations.