# Spin buffers **URL:** \ **Category:** Ruby\ **Created:** [July 16, 2007, 4:28am UTC](https://www.ruby-forum.com/t/spin-buffers/109507 "2007-07-16T04:28:47Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![amin1426](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/4da419/32.png) [@amin1426](https://www.ruby-forum.com/u/amin1426)\ **Post date:** [July 16, 2007, 4:28am UTC](https://www.ruby-forum.com/t/spin-buffers/109507/1 "2007-07-16T04:28:47Z")
Hmm. Just being reading the Dr. Dobbs. I certainly have hit the bottleneck talked about in this article… [Spin Buffers | Dr Dobb's](http://www.ddj.com/dept/architect/199902669) when using the ‘thread.rb’ Queue class. I hacked around it by creating a Queue of Arrays, but that probably creates more garbage than I should. This “Spin Buffer” trick looks Good… [http://www.ddj.com/dept/architect/199902669?pgno=2](http://www.ddj.com/dept/architect/199902669?pgno=2) Anyone have a ruby Spin Buffer implementation lying around? John C. Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : removed\_email\_address@domain.invalid New Zealand ---
**Author:** ![amin1426](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/4da419/32.png) [@amin1426](https://www.ruby-forum.com/u/amin1426)\ **Post date:** [July 16, 2007, 7:32am UTC](https://www.ruby-forum.com/t/spin-buffers/109507/2 "2007-07-16T07:32:59Z")
On 16.07.2007 04:20, John C. wrote: > Hmm. Just being reading the Dr. Dobbs. > > I certainly have hit the bottleneck talked about in this article… > [http://www.ddj.com/dept/architect/199902669](http://www.ddj.com/dept/architect/199902669) > when using the ‘thread.rb’ Queue class. What exactly makes you believe that? Can you show some code and / or figures that back this theory? > I hacked around it by creating a Queue of Arrays, but that probably > creates more garbage than I should. Difficult to say without seeing the code. Generally I’d say that Queue is pretty efficient already since it’s implemented in C AFAIR. > This “Spin Buffer” trick looks Good… > [http://www.ddj.com/dept/architect/199902669?pgno=2](http://www.ddj.com/dept/architect/199902669?pgno=2) > > Anyone have a ruby Spin Buffer implementation lying around? I’d check with the RAA. Kind regards robert ---
**Author:** ![amin1426](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/4da419/32.png) [@amin1426](https://www.ruby-forum.com/u/amin1426)\ **Post date:** [July 16, 2007, 7:47am UTC](https://www.ruby-forum.com/t/spin-buffers/109507/3 "2007-07-16T07:47:00Z")
On Jul 15, 2007, at 8:20 PM, John C. wrote: > Anyone have a ruby Spin Buffer implementation lying around? no, but i’d be inclined to try writing one on top of guy’s mmap ext - the interface is that of string so the example should map (no pun intended) rather well. cheers. a @ [http://drawohara.com/](http://drawohara.com/) ---
**Author:** ![amin1426](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/4da419/32.png) [@amin1426](https://www.ruby-forum.com/u/amin1426)\ **Post date:** [July 18, 2007, 2:58am UTC](https://www.ruby-forum.com/t/spin-buffers/109507/4 "2007-07-18T02:58:02Z")
On Mon, 2007-07-16 at 14:30 +0900, Robert K. wrote: > What exactly makes you believe that? Can you show some code and / or > figures that back this theory? Seconded. Measure first, then optimize. > > I hacked around it by creating a Queue of Arrays, but that probably > > creates more garbage than I should. That probably performs slower than Queue. > Difficult to say without seeing the code. Generally I’d say that Queue > is pretty efficient already since it’s implemented in C AFAIR. Depends on the version of Ruby. It certainly is if you’re using fastthread. If he’s not using fastthread, I’d recommend giving it a try. > > This “Spin Buffer” trick looks Good… > > [http://www.ddj.com/dept/architect/199902669?pgno=2](http://www.ddj.com/dept/architect/199902669?pgno=2) > > > > Anyone have a ruby Spin Buffer implementation lying around? “Spin Buffers” are _snake oil_; they get their “speed” at the expense of correctness – the implementation given in the DDJ article is not threadsafe. If it were rewritten to be threadsafe, it would actually be slower than some simpler alternatives. -mental ---
**Author:** ![amin1426](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/4da419/32.png) [@amin1426](https://www.ruby-forum.com/u/amin1426)\ **Post date:** [July 18, 2007, 3:33am UTC](https://www.ruby-forum.com/t/spin-buffers/109507/5 "2007-07-18T03:33:04Z")
On Wed, 18 Jul 2007, MenTaLguY wrote: And yes… I did, as always, measure before I optimized and my Queue of Array trick did speed things measurably. > Depends on the version of Ruby. It certainly is if you’re using > fastthread. If he’s not using fastthread, I’d recommend giving it a > try. I’m not using fastthread since it caused code that had been working fine for several years to curl up and die. So I disabled it. I’ll admit I never got to the bottom of why it did… (and no, it wasn’t the code that used my queue of arrays trick) > > > This “Spin Buffer” trick looks Good… > > > [http://www.ddj.com/dept/architect/199902669?pgno=2](http://www.ddj.com/dept/architect/199902669?pgno=2) > > > > > > Anyone have a ruby Spin Buffer implementation lying around? > “Spin Buffers” are _snake oil_; they get their “speed” at the expense of > correctness – the implementation given in the DDJ article is not > threadsafe. Well that was a bit of a problem with the article… it didn’t actually include the code so I can’t say one way or the other on that. Any pointers as to what the incorrect bit is? John C. Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : removed\_email\_address@domain.invalid New Zealand ---
**Author:** ![amin1426](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/4da419/32.png) [@amin1426](https://www.ruby-forum.com/u/amin1426)\ **Post date:** [July 18, 2007, 3:00am UTC](https://www.ruby-forum.com/t/spin-buffers/109507/6 "2007-07-18T03:00:03Z")
On Mon, 2007-07-16 at 14:46 +0900, ara.t.howard wrote: > no, but i’d be inclined to try writing one on top of guy’s mmap ext - > the interface is that of string so the example should map (no pun > intended) rather well. What does mmap have to do with communication between Ruby threads? (and again, I’d like to emphasize that “spin buffers” are snake oil) -mental ---
**Author:** ![amin1426](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/4da419/32.png) [@amin1426](https://www.ruby-forum.com/u/amin1426)\ **Post date:** [July 18, 2007, 4:30am UTC](https://www.ruby-forum.com/t/spin-buffers/109507/7 "2007-07-18T04:30:22Z")
On Wed, 2007-07-18 at 10:32 +0900, John C. wrote: > And yes… I did, as always, measure before I optimized and my Queue > of Array trick did speed things measurably. Hmm, did you just mean sending batches of objects as arrays, rather than sending individual objects? That would make sense and it’s a reasonable optimization, provided you’re careful about not touching the array on the sending side once it’s been added to the queue. I’d just finished reading the DDJ article and was imagining something more elaborate at first… > > Depends on the version of Ruby. It certainly is if you’re using > > fastthread. If he’s not using fastthread, I’d recommend giving it a > > try. > > I’m not using fastthread since it caused code that had been working > fine for several years to curl up and die. So I disabled it. It might be worth looking into why – if it doesn’t work with fastthread, it’s unlikely to work with future versions of Ruby (including 1.8.6 or later) or alternate Ruby implementations like JRuby. Absent fastthread bugs (which do crop up occasionally, though rarely at this point), there are two main sources of problems: 1. Code that tries to manipulate the internal implementation of thread.rb objects (Mutex, ConditionVariable, Queue, etc); not always a bug, but it isn’t portable or future-proof. 2. Code which has existing concurrency bugs which show up more clearly when the scheduling behavior changes. > > “Spin Buffers” are _snake oil_; they get their “speed” at the expense of > > correctness – the implementation given in the DDJ article is not > > threadsafe. > > Well that was a bit of a problem with the article… it didn’t > actually include the code so I can’t say one way or the other on > that. Any pointers as to what the incorrect bit is? The code is included in the source archive on the DDJ ftp site as spin.txt (and spin.zip, which has his test harness): ftp://66.77.27.238/sourcecode/ddj/2007/0707.zip It’s not just a one-line bug, but a systemic problem: the author assumes that the only reason he needs synchronization is to prevent two threads from modifying the same data at the same time (hence the elaborate dance with the buffers); in reality, however, it’s also important to protect the code from compiler (and CPU) optimizations which will alter its behavior in undesirable ways if it is used in a multi-threaded context (e.g. it becomes possible for the reader to see the writer’s addition of the object but see the object in an uninitalized state!). He’s basically trying to get a performance “free lunch” by not using synchronization. Concurrency bugs are notoriously hard to find through testing, and it doesn’t help that the author only ever tested on hardware which is extremely forgiving about concurrency (a single hyperthreaded x86 CPU). It also didn’t help that all his test did was count how many objects were read from the queue. -mental ---
**Author:** ![amin1426](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/4da419/32.png) [@amin1426](https://www.ruby-forum.com/u/amin1426)\ **Post date:** [July 18, 2007, 4:56am UTC](https://www.ruby-forum.com/t/spin-buffers/109507/8 "2007-07-18T04:56:27Z")
On Wed, 2007-07-18 at 11:29 +0900, MenTaLguY wrote: > in reality, however, it’s also important to protect > the code from compiler (and CPU) optimizations which will alter its > behavior in undesirable ways if it is used in a multi-threaded context > (e.g. it becomes possible for the reader to see the writer’s addition of > the object but see the object in an uninitalized state!). It is worth noting that these are not issues if you’re only writing for Ruby 1.8, which has neither an optimizing compiler nor native threads (where instruction ordering and cache effects become a consideration). So, does that mean a Spin Buffer implementation would theoretically be okay for Ruby 1.8? Maybe as far as those issues go. But note that the author himself identifies a number of issues with spin buffers when the readers and writers get out of sync, including poor performance and the reader getting “stuck” on a non-empty buffer if it hits a buffer boundary when no writers are writing. Those are actually inherent to the data structure’s design. -mental ---
**Author:** ![amin1426](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/4da419/32.png) [@amin1426](https://www.ruby-forum.com/u/amin1426)\ **Post date:** [July 18, 2007, 4:44am UTC](https://www.ruby-forum.com/t/spin-buffers/109507/9 "2007-07-18T04:44:25Z")
On Wed, 2007-07-18 at 10:32 +0900, John C. wrote: > I’m not using fastthread since it caused code that had been working > fine for several years to curl up and die. So I disabled it. At any rate, I think your best option is something like fastthread’s Queue. It shouldn’t be too hard to change the code to work with it, and it’s possible that you’ve uncovered a bug in that “working” code which really needs to be fixed. -mental