concurrency

Comments on Comments…part 2: Some Example Code…

Sunday, 4 Aug 2013 - 15:49 +0100 by Ralph McArdell code, C++, GotW, concurrency

I have posted some example code on GitHub showing the Shared Immutable, Exclusive Setup ideas discussed in the Comments on comments to Herb Sutter’s updated GotW #6b solution (part 2) blog post to demonstrate the ideas: https://github.com/ralph-mcardell/dibase-blog-sharedimmutable-exclusivesetup My thought was to create a type that was not just a simple chunk of memory, create wrapper types to add support for the intrusive Shared Immutable, Exclusive Setup pattern discussed in the blog post that allowed for easy specification of atomic and memory order policy.

Comments on comments to Herb Sutter's updated GotW #6b solution (part 2)

Monday, 8 Jul 2013 - 15:53 +0100 by Ralph McArdell code, C++, GotW, concurrency

Previously[1] I wondered, from musing when reading Herb Sutter’s updated Guru of the Week 6b[2] article, how one might – in C++11 – enforce a concurrent usage pattern in which an object can only be modified after creation by the creating thread until all modifications are done when the object becomes immutable and concurrently accessible. Concurrent access before an object becomes immutable is considered an error as are attempts to modify an object that is immutable.

Comments on comments to Herb Sutter's updated GotW #6b solution (part 1)

Friday, 31 May 2013 - 16:49 +0100 by Ralph McArdell code, C++, GotW, concurrency

I have been following Herb Sutter on his Sutter’s Mill[1] website and while reading the solution and comments to the posted solution to GotW #6b Solution: Const-Correctness, Part 2[2] some thoughts popped into my head. First to catch my eye were some comments on the overhead that may be incurred by std::atomic being only to do with what liberties the compiler can take with respect to optimising writes. This raised an eyebrow as I was under the impression that the need to force atomic operation effects to be globally and consistently visible has more of an effect on performance than reordering write restrictions.