Don't be hasty. It was a horrible hack. I repent. On 24 Jan 2011, at 16:34, Robert Ash wrote:
> > > > Robert Ash > ---------- > > > On 24 Jan 2011, at 16:25, macruby-devel-requ...@lists.macosforge.org wrote: > >> Send MacRuby-devel mailing list submissions to >> macruby-devel@lists.macosforge.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> or, via email, send a message with subject or body 'help' to >> macruby-devel-requ...@lists.macosforge.org >> >> You can reach the person managing the list at >> macruby-devel-ow...@lists.macosforge.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of MacRuby-devel digest..." >> >> >> Today's Topics: >> >> 1. Re: Thread safety in apply example? (Matt Massicotte) >> 2. Re: Thread safety in apply example? (Alan Skipp) >> 3. Re: Thread safety in apply example? (Matt Massicotte) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 24 Jan 2011 07:22:44 -0800 >> From: Matt Massicotte <massico...@apple.com> >> To: "MacRuby development discussions." >> <macruby-devel@lists.macosforge.org> >> Subject: Re: [MacRuby-devel] Thread safety in apply example? >> Message-ID: <48dbc4a8-59d1-42f0-8dd3-2291668d6...@apple.com> >> Content-Type: text/plain; charset="us-ascii" >> >> What's the advantage of this over just iterating over the array serially >> using each? >> >> Matt >> >> On Jan 24, 2011, at 3:40 AM, Alan Skipp wrote: >> >>> Warning, horrible hack alert! >>> I'm sure there must be a far better implementation, but the idea is to have >>> an array subclass which diverts all method calls through a serial dispatch >>> queue, which should ensure thread safe access. >>> >>> Anyway, here's the horrible hack. By the way, it manages to break >>> Enumerable, other than that it's perfect! >>> >>> class ThreadSafeArray < Array >>> instance_methods.each do |meth| >>> eval " >>> def #{meth}(*args, &block) >>> val = [] >>> @serial_queue.async(@group) do >>> val[0] = super >>> end >>> @group.wait >>> val[0] >>> end" >>> end >>> >>> def initialize(size=0, obj=nil) >>> @serial_queue = Dispatch::Queue.new("array.serial_queue") >>> @group = Dispatch::Group.new >>> super >>> end >>> end >>> >>> gcdq = Dispatch::Queue.new('doc') >>> @result = ThreadSafeArray.new >>> gcdq.apply(5) {|i| @result[i] = i*i } >>> p @result #=> [0, 1, 4, 9, 16, 25] >>> >>> >>> Having to create an array for every method call to copy the return value >>> into is terrible, is there a better way of getting a reference to the >>> return value from a dispatch queue? >>> >>> >>> >>> On 22 Jan 2011, at 14:52, Ernest N. Prabhakar, Ph.D. wrote: >>> >>>> Hi Charles, >>>> >>>> On Jan 21, 2011, at 9:57 PM, Charles Oliver Nutter wrote: >>>> >>>>> I'm curious about this example in Queue#apply's rdoc: >>>>> >>>>> * gcdq = Dispatch::Queue.new('doc') >>>>> * @result = [] >>>>> * gcdq.apply(5) {|i| @result[i] = i*i } >>>>> * p @result #=> [0, 1, 4, 9, 16, 25] >>>>> >>>>> apply is said to issue the jobs in parallel, so this would be making >>>>> concurrent updates to the @result array. Are simple arrays in MacRuby >>>>> thread-safe? >>>> >>>> My assumption was that doing a parallel assign: >>>> >>>> result[i] = i*i >>>> >>>> would be safe, since it always accessed a unique portion of memory, but >>>> doing a serial append: >>>> >>>> result << i*i >>>> >>>> would not. But that may have been a mistake on my part, since the size >>>> (at least) needs to be updated. Anyone know better? >>>> >>>> -- Ernie P. >>>> >>>> >>>>> >>>>> - Charlie >>>>> _______________________________________________ >>>>> MacRuby-devel mailing list >>>>> MacRuby-devel@lists.macosforge.org >>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>>> >>>> _______________________________________________ >>>> MacRuby-devel mailing list >>>> MacRuby-devel@lists.macosforge.org >>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>> >>> _______________________________________________ >>> MacRuby-devel mailing list >>> MacRuby-devel@lists.macosforge.org >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: smime.p7s >> Type: application/pkcs7-signature >> Size: 3737 bytes >> Desc: not available >> URL: >> <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20110124/ce20626d/attachment-0001.bin> >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 24 Jan 2011 16:00:41 +0000 >> From: Alan Skipp <al_sk...@fastmail.fm> >> To: "MacRuby development discussions." >> <macruby-devel@lists.macosforge.org> >> Subject: Re: [MacRuby-devel] Thread safety in apply example? >> Message-ID: <184bdafb-c983-43af-8908-912380237...@fastmail.fm> >> Content-Type: text/plain; charset=us-ascii >> >> The post was admittedly vague, but was more of an idea about a general >> purpose thread safe array class (in principle, this could apply to any >> mutable class). Perhaps implemented as a module that would redirect all >> method calls through a serial dispatch queue. This would mean that the array >> (or other mutable collection) could be mutated from multiple threads/queues >> without fear of bad things happening. >> >> On 24 Jan 2011, at 15:22, Matt Massicotte wrote: >> >>> What's the advantage of this over just iterating over the array serially >>> using each? >>> >>> Matt >>> >>> On Jan 24, 2011, at 3:40 AM, Alan Skipp wrote: >>> >>>> Warning, horrible hack alert! >>>> I'm sure there must be a far better implementation, but the idea is to >>>> have an array subclass which diverts all method calls through a serial >>>> dispatch queue, which should ensure thread safe access. >>>> >>>> Anyway, here's the horrible hack. By the way, it manages to break >>>> Enumerable, other than that it's perfect! >>>> >>>> class ThreadSafeArray < Array >>>> instance_methods.each do |meth| >>>> eval " >>>> def #{meth}(*args, &block) >>>> val = [] >>>> @serial_queue.async(@group) do >>>> val[0] = super >>>> end >>>> @group.wait >>>> val[0] >>>> end" >>>> end >>>> >>>> def initialize(size=0, obj=nil) >>>> @serial_queue = Dispatch::Queue.new("array.serial_queue") >>>> @group = Dispatch::Group.new >>>> super >>>> end >>>> end >>>> >>>> gcdq = Dispatch::Queue.new('doc') >>>> @result = ThreadSafeArray.new >>>> gcdq.apply(5) {|i| @result[i] = i*i } >>>> p @result #=> [0, 1, 4, 9, 16, 25] >>>> >>>> >>>> Having to create an array for every method call to copy the return value >>>> into is terrible, is there a better way of getting a reference to the >>>> return value from a dispatch queue? >>>> >>>> >>>> >>>> On 22 Jan 2011, at 14:52, Ernest N. Prabhakar, Ph.D. wrote: >>>> >>>>> Hi Charles, >>>>> >>>>> On Jan 21, 2011, at 9:57 PM, Charles Oliver Nutter wrote: >>>>> >>>>>> I'm curious about this example in Queue#apply's rdoc: >>>>>> >>>>>> * gcdq = Dispatch::Queue.new('doc') >>>>>> * @result = [] >>>>>> * gcdq.apply(5) {|i| @result[i] = i*i } >>>>>> * p @result #=> [0, 1, 4, 9, 16, 25] >>>>>> >>>>>> apply is said to issue the jobs in parallel, so this would be making >>>>>> concurrent updates to the @result array. Are simple arrays in MacRuby >>>>>> thread-safe? >>>>> >>>>> My assumption was that doing a parallel assign: >>>>> >>>>> result[i] = i*i >>>>> >>>>> would be safe, since it always accessed a unique portion of memory, but >>>>> doing a serial append: >>>>> >>>>> result << i*i >>>>> >>>>> would not. But that may have been a mistake on my part, since the size >>>>> (at least) needs to be updated. Anyone know better? >>>>> >>>>> -- Ernie P. >>>>> >>>>> >>>>>> >>>>>> - Charlie >>>>>> _______________________________________________ >>>>>> MacRuby-devel mailing list >>>>>> MacRuby-devel@lists.macosforge.org >>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>>>> >>>>> _______________________________________________ >>>>> MacRuby-devel mailing list >>>>> MacRuby-devel@lists.macosforge.org >>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>>> >>>> _______________________________________________ >>>> MacRuby-devel mailing list >>>> MacRuby-devel@lists.macosforge.org >>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>> >>> _______________________________________________ >>> MacRuby-devel mailing list >>> MacRuby-devel@lists.macosforge.org >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Mon, 24 Jan 2011 08:24:04 -0800 >> From: Matt Massicotte <massico...@apple.com> >> To: "MacRuby development discussions." >> <macruby-devel@lists.macosforge.org> >> Subject: Re: [MacRuby-devel] Thread safety in apply example? >> Message-ID: <1a135050-6824-4d8b-bfb3-03003143d...@apple.com> >> Content-Type: text/plain; charset="us-ascii" >> >> My guess is that most problems need a thread-safe mechanism, where >> manipulating an array is just one part of a more complex system. Pushing >> the details of the thread-safety into the array just hides the problem, and >> will likely trade more locking for possibly simpler code. >> >> Which could be a very good trade, don't get me wrong. I'm not trying to >> knock your implementation at all. >> >> I'm just saying that achieving parallelism actually is hard. I've been much >> better served (though, admittedly, not in Ruby) by trying to get really >> familiar with the queue paradigm and understanding how to use them in place >> of traditional locks and threads. >> >> I think the actual underlying problem here is Queue#apply's rdoc entry. >> Manipulating a non-thread-safe data structure (which is all of Foundation's >> collection classes) in an apply is a bug and even worse a conceptual error. >> Where do you open bugs on the dispatch gem? >> >> Matt >> >> On Jan 24, 2011, at 8:00 AM, Alan Skipp wrote: >> >>> The post was admittedly vague, but was more of an idea about a general >>> purpose thread safe array class (in principle, this could apply to any >>> mutable class). Perhaps implemented as a module that would redirect all >>> method calls through a serial dispatch queue. This would mean that the >>> array (or other mutable collection) could be mutated from multiple >>> threads/queues without fear of bad things happening. >>> >>> On 24 Jan 2011, at 15:22, Matt Massicotte wrote: >>> >>>> What's the advantage of this over just iterating over the array serially >>>> using each? >>>> >>>> Matt >>>> >>>> On Jan 24, 2011, at 3:40 AM, Alan Skipp wrote: >>>> >>>>> Warning, horrible hack alert! >>>>> I'm sure there must be a far better implementation, but the idea is to >>>>> have an array subclass which diverts all method calls through a serial >>>>> dispatch queue, which should ensure thread safe access. >>>>> >>>>> Anyway, here's the horrible hack. By the way, it manages to break >>>>> Enumerable, other than that it's perfect! >>>>> >>>>> class ThreadSafeArray < Array >>>>> instance_methods.each do |meth| >>>>> eval " >>>>> def #{meth}(*args, &block) >>>>> val = [] >>>>> @serial_queue.async(@group) do >>>>> val[0] = super >>>>> end >>>>> @group.wait >>>>> val[0] >>>>> end" >>>>> end >>>>> >>>>> def initialize(size=0, obj=nil) >>>>> @serial_queue = Dispatch::Queue.new("array.serial_queue") >>>>> @group = Dispatch::Group.new >>>>> super >>>>> end >>>>> end >>>>> >>>>> gcdq = Dispatch::Queue.new('doc') >>>>> @result = ThreadSafeArray.new >>>>> gcdq.apply(5) {|i| @result[i] = i*i } >>>>> p @result #=> [0, 1, 4, 9, 16, 25] >>>>> >>>>> >>>>> Having to create an array for every method call to copy the return value >>>>> into is terrible, is there a better way of getting a reference to the >>>>> return value from a dispatch queue? >>>>> >>>>> >>>>> >>>>> On 22 Jan 2011, at 14:52, Ernest N. Prabhakar, Ph.D. wrote: >>>>> >>>>>> Hi Charles, >>>>>> >>>>>> On Jan 21, 2011, at 9:57 PM, Charles Oliver Nutter wrote: >>>>>> >>>>>>> I'm curious about this example in Queue#apply's rdoc: >>>>>>> >>>>>>> * gcdq = Dispatch::Queue.new('doc') >>>>>>> * @result = [] >>>>>>> * gcdq.apply(5) {|i| @result[i] = i*i } >>>>>>> * p @result #=> [0, 1, 4, 9, 16, 25] >>>>>>> >>>>>>> apply is said to issue the jobs in parallel, so this would be making >>>>>>> concurrent updates to the @result array. Are simple arrays in MacRuby >>>>>>> thread-safe? >>>>>> >>>>>> My assumption was that doing a parallel assign: >>>>>> >>>>>> result[i] = i*i >>>>>> >>>>>> would be safe, since it always accessed a unique portion of memory, but >>>>>> doing a serial append: >>>>>> >>>>>> result << i*i >>>>>> >>>>>> would not. But that may have been a mistake on my part, since the size >>>>>> (at least) needs to be updated. Anyone know better? >>>>>> >>>>>> -- Ernie P. >>>>>> >>>>>> >>>>>>> >>>>>>> - Charlie >>>>>>> _______________________________________________ >>>>>>> MacRuby-devel mailing list >>>>>>> MacRuby-devel@lists.macosforge.org >>>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>>>>> >>>>>> _______________________________________________ >>>>>> MacRuby-devel mailing list >>>>>> MacRuby-devel@lists.macosforge.org >>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>>>> >>>>> _______________________________________________ >>>>> MacRuby-devel mailing list >>>>> MacRuby-devel@lists.macosforge.org >>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>>> >>>> _______________________________________________ >>>> MacRuby-devel mailing list >>>> MacRuby-devel@lists.macosforge.org >>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>> >>> _______________________________________________ >>> MacRuby-devel mailing list >>> MacRuby-devel@lists.macosforge.org >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: smime.p7s >> Type: application/pkcs7-signature >> Size: 3737 bytes >> Desc: not available >> URL: >> <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20110124/f4957820/attachment.bin> >> >> ------------------------------ >> >> _______________________________________________ >> MacRuby-devel mailing list >> MacRuby-devel@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> >> >> End of MacRuby-devel Digest, Vol 35, Issue 61 >> ********************************************* > _______________________________________________ > MacRuby-devel mailing list > MacRuby-devel@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
