Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The main reason for observing the sequential filling of the output buffer is that you threads complete too soon. 200 iterations are not enough for the worker threads to be interrupted. Instead of printing output, I appended this to your <code>main()</code>:</p> <pre><code>int switches = 0; for (int i=1; i&lt;iterations*4; ++i) if (output[i] != output[i-1]) ++switches; std::cout &lt;&lt; "Switches = " &lt;&lt; switches &lt;&lt; "\n"; </code></pre> <p>and started increasing <code>iterations</code>. Indeed, at some point (around 10,000,000 on my box) thread switches became apparent. That immediately revealed another problem with your program: increments of <code>k</code> are not atomic. You've declared <code>k</code> as volatile which means the compiler won't cache its value in a register when repeatedly checking it, like you do in the empty loop in <code>main</code>. However, volatile doesn't at all guarantee atomic increments. What does this mean in practice is when actual thread switches occur, <code>k++</code> doesn't always increment and the <code>while (k&lt;iterations*4) {}</code> loop will never terminate. To increment <code>k</code> atomically you need yet another external library - <a href="https://stackoverflow.com/questions/1158374/portable-compare-and-swap-atomic-operations-c-c-library">here's a discussion on the topic on SO</a>. If you happen to be on Windows, it might be easier to use <a href="http://msdn.microsoft.com/en-us/library/ms683614%28v=vs.85%29.aspx" rel="nofollow noreferrer">InterlockedIncrement</a> directly. If you do those changes to your program, you'll see the result you are expecting.</p> <hr> <p>There's also a subtle buffer overflow of output. Since you are incrementing k before writing to output, you are writing to indexes from 1 to iterations*4 included. You either need to initialize k to -1 or add one more element to the array</p>
    singulars
    1. This table or related slice is empty.
    1. POBoost Threads - Racing
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USsbk
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POBoost Threads - Racing
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. CO+1 The `k++` non-atomic increment issue is the reason why you should never consider `volatile` as a primitive for multithreading. In a few cases (the check in main, assuming the increments were correct) it might be appropriate, but in most cases it will just not be enough.
      singulars
      1. PO
      1. USDavid Rodríguez - dribeas
    2. CO@David Rodriguez: My suggestion of `volatile` in my answer was a 'quick and dirty hack'. I should've been explicit that it isn't really a solution.
      singulars
      1. PO
      1. USOmnifarious
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload