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
