http://www.mikeash.com/?page=pyblog/friday-qa-2012-02-17-ring-buffers-and-mirrored-memory-part-ii.html#commentsmikeash.com Recent CommentsSun, 12 Apr 2026 02:30:22 GMTPyRSS2Gen-1.0.0http://blogs.law.harvard.edu/tech/rsshttp://www.mikeash.com/?page=pyblog/friday-qa-2012-02-17-ring-buffers-and-mirrored-memory-part-ii.html#commentsNice article as always. <br /> <br />s/hting/thing/ <br />69d9d8cd9b65260608eee20aef2af5c0Sun, 24 Jun 2012 06:54:06 GMThttp://www.mikeash.com/?page=pyblog/friday-qa-2012-02-17-ring-buffers-and-mirrored-memory-part-ii.html#commentsIt's not, no. The API as-is is inherently unsafe for that scenario, since reading/writing are separate from advancing the pointer. I'm not sure offhand how you'd make it safe for multiple readers or writers, but it would probably have to start with an atomic get-and-advance-pointer operation, and some more bookkeeping to distinguish between areas that are data, free, or pending data.f5f1bf5541b5cd15f97c0d02d889dc58Sat, 12 May 2012 02:46:43 GMThttp://www.mikeash.com/?page=pyblog/friday-qa-2012-02-17-ring-buffers-and-mirrored-memory-part-ii.html#commentsIs the code thread-safe for multiple reader and/or writer threads? I have a guess as to how to add that, but guessing and thread-safety don't mix well.b8a0765dcea588e190d4868b8ed32242Sat, 12 May 2012 01:20:32 GMT