[MacRuby-devel] Unsubscribe
Robert Ash
robertgash at me.com
Mon Jan 24 08:34:10 PST 2011
Robert Ash
----------
On 24 Jan 2011, at 16:25, macruby-devel-request at lists.macosforge.org wrote:
> Send MacRuby-devel mailing list submissions to
> macruby-devel at 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-request at lists.macosforge.org
>
> You can reach the person managing the list at
> macruby-devel-owner at 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 <massicotte at apple.com>
> To: "MacRuby development discussions."
> <macruby-devel at lists.macosforge.org>
> Subject: Re: [MacRuby-devel] Thread safety in apply example?
> Message-ID: <48DBC4A8-59D1-42F0-8DD3-2291668D64D2 at 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 at lists.macosforge.org
>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>>
>>> _______________________________________________
>>> MacRuby-devel mailing list
>>> MacRuby-devel at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
>> _______________________________________________
>> MacRuby-devel mailing list
>> MacRuby-devel at 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_skipp at fastmail.fm>
> To: "MacRuby development discussions."
> <macruby-devel at lists.macosforge.org>
> Subject: Re: [MacRuby-devel] Thread safety in apply example?
> Message-ID: <184BDAFB-C983-43AF-8908-912380237B52 at 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 at lists.macosforge.org
>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>>>
>>>> _______________________________________________
>>>> MacRuby-devel mailing list
>>>> MacRuby-devel at lists.macosforge.org
>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>>
>>> _______________________________________________
>>> MacRuby-devel mailing list
>>> MacRuby-devel at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
>> _______________________________________________
>> MacRuby-devel mailing list
>> MacRuby-devel at 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 <massicotte at apple.com>
> To: "MacRuby development discussions."
> <macruby-devel at lists.macosforge.org>
> Subject: Re: [MacRuby-devel] Thread safety in apply example?
> Message-ID: <1A135050-6824-4D8B-BFB3-03003143D488 at 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 at lists.macosforge.org
>>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>>>>
>>>>> _______________________________________________
>>>>> MacRuby-devel mailing list
>>>>> MacRuby-devel at lists.macosforge.org
>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>>>
>>>> _______________________________________________
>>>> MacRuby-devel mailing list
>>>> MacRuby-devel at lists.macosforge.org
>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>>
>>> _______________________________________________
>>> MacRuby-devel mailing list
>>> MacRuby-devel at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
>> _______________________________________________
>> MacRuby-devel mailing list
>> MacRuby-devel at 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 at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
>
> End of MacRuby-devel Digest, Vol 35, Issue 61
> *********************************************
More information about the MacRuby-devel
mailing list