thread-safety and collections in macruby
In ObjC, the immutable collections are threadsafe. In macruby, are collections threadsafe to read only? ie, if I do this: a = [ ...] # an array that may or may not be changed b = a.dup # nowhere in the code is b ever used to add/delete/change an element is b thread-safe to read from multiple threads (queued operations/blocks)? also, is there any difference between doing b = a.dup and b = NSArray.arrayWithArray(a) Both result in class Array, so I assume there is no difference. Cheerio, Michael Johnston lastobelus@mac.com
Note, in my example I can also guarantee that none of the elements in b are going to be changed (for example, an array of strings) Cheerio, Michael Johnston lastobelus@mac.com On 2011-10-18, at 10:17 PM, Michael Johnston wrote:
In ObjC, the immutable collections are threadsafe.
In macruby, are collections threadsafe to read only?
ie, if I do this:
a = [ ...] # an array that may or may not be changed
b = a.dup # nowhere in the code is b ever used to add/delete/change an element
is b thread-safe to read from multiple threads (queued operations/blocks)?
also, is there any difference between doing
b = a.dup
and
b = NSArray.arrayWithArray(a)
Both result in class Array, so I assume there is no difference.
Cheerio,
Michael Johnston lastobelus@mac.com
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
If you're not wring/changing the array no problems. But to be safe use Object#freeze... Terry Moore On 19/10/2011, at 6:26 PM, Michael Johnston <lastobelus@mac.com> wrote:
Note, in my example I can also guarantee that none of the elements in b are going to be changed (for example, an array of strings) Cheerio,
Michael Johnston lastobelus@mac.com
On 2011-10-18, at 10:17 PM, Michael Johnston wrote:
In ObjC, the immutable collections are threadsafe.
In macruby, are collections threadsafe to read only?
ie, if I do this:
a = [ ...] # an array that may or may not be changed
b = a.dup # nowhere in the code is b ever used to add/delete/change an element
is b thread-safe to read from multiple threads (queued operations/blocks)?
also, is there any difference between doing
b = a.dup
and
b = NSArray.arrayWithArray(a)
Both result in class Array, so I assume there is no difference.
Cheerio,
Michael Johnston lastobelus@mac.com
_______________________________________________ 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
On Oct 19, 2011, at 12:41 AM, Terry Moore wrote:
If you're not wring/changing the array no problems. But to be safe use Object#freeze...
Terry Moore
On 19/10/2011, at 6:26 PM, Michael Johnston <lastobelus@mac.com> wrote:
Note, in my example I can also guarantee that none of the elements in b are going to be changed (for example, an array of strings)
Object#freeze is a terrible method. Supporting it requires an extra check (#frozen?) in every method that tries to modify an object. This is why Ruby is slow (certainly not the only reason, but decisions like this are everywhere). :) Using #freeze won't save you but it will throw a RuntimeException if you try to modify a frozen object. So it's really only good for pointing out that you have a bug when you attempt to modify your immutable array. cr
The proper way to protect mutable objects is to use a mutex: http://www.ruby-doc.org/core-1.9.2/Mutex.html - Matt Sent from my iPhone On Oct 19, 2011, at 8:06, Chuck Remes <cremes.devlist@mac.com> wrote:
On Oct 19, 2011, at 12:41 AM, Terry Moore wrote:
If you're not wring/changing the array no problems. But to be safe use Object#freeze...
Terry Moore
On 19/10/2011, at 6:26 PM, Michael Johnston <lastobelus@mac.com> wrote:
Note, in my example I can also guarantee that none of the elements in b are going to be changed (for example, an array of strings)
Object#freeze is a terrible method. Supporting it requires an extra check (#frozen?) in every method that tries to modify an object. This is why Ruby is slow (certainly not the only reason, but decisions like this are everywhere).
:)
Using #freeze won't save you but it will throw a RuntimeException if you try to modify a frozen object. So it's really only good for pointing out that you have a bug when you attempt to modify your immutable array.
cr
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Yes. But he does state it is a read only not modified array. My understanding is. 'Array' is an NSMutableArray, I was merely suggesting using freeze to throw that exception just in case there maybe some code attempting to write/modify. Mutex is the way to go but it also has an overhead. Terry Moore On 20/10/2011, at 4:28 AM, Matt Aimonetti <mattaimonetti@gmail.com> wrote:
The proper way to protect mutable objects is to use a mutex: http://www.ruby-doc.org/core-1.9.2/Mutex.html
- Matt
Sent from my iPhone
On Oct 19, 2011, at 8:06, Chuck Remes <cremes.devlist@mac.com> wrote:
On Oct 19, 2011, at 12:41 AM, Terry Moore wrote:
If you're not wring/changing the array no problems. But to be safe use Object#freeze...
Terry Moore
On 19/10/2011, at 6:26 PM, Michael Johnston <lastobelus@mac.com> wrote:
Note, in my example I can also guarantee that none of the elements in b are going to be changed (for example, an array of strings)
Object#freeze is a terrible method. Supporting it requires an extra check (#frozen?) in every method that tries to modify an object. This is why Ruby is slow (certainly not the only reason, but decisions like this are everywhere).
:)
Using #freeze won't save you but it will throw a RuntimeException if you try to modify a frozen object. So it's really only good for pointing out that you have a bug when you attempt to modify your immutable array.
cr
_______________________________________________ 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
On Oct 19, 2011, at 11:38 AM, Terry Moore wrote:
Yes. But he does state it is a read only not modified array. My understanding is. 'Array' is an NSMutableArray, I was merely suggesting using freeze to throw that exception just in case there maybe some code attempting to write/modify.
Mutex is the way to go but it also has an overhead.
Didn't somebody (Ernie?) already post a set of mix-ins for the mutable object classes that used a per-object GCD queue to serialize operations against the object? If the mail archives were easier to search, I'd pull it up, but it isn't and I'm too lazy. :) - Jordan
I believe someone (Ernie or someone else) did indeed extract some of the dispatch gem's mixins. - Matt On Wed, Oct 19, 2011 at 1:43 PM, Jordan K. Hubbard <jkh@apple.com> wrote:
On Oct 19, 2011, at 11:38 AM, Terry Moore wrote:
Yes. But he does state it is a read only not modified array. My understanding is. 'Array' is an NSMutableArray, I was merely suggesting using freeze to throw that exception just in case there maybe some code attempting to write/modify.
Mutex is the way to go but it also has an overhead.
Didn't somebody (Ernie?) already post a set of mix-ins for the mutable object classes that used a per-object GCD queue to serialize operations against the object? If the mail archives were easier to search, I'd pull it up, but it isn't and I'm too lazy. :)
- Jordan
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
I found that searching the google groups mirror was much easier and this might be the thread you're referring to: https://groups.google.com/d/topic/macruby/ceyNNqComMc/discussion -sas On Oct 19, 2011, at 22:43, Jordan K. Hubbard wrote:
On Oct 19, 2011, at 11:38 AM, Terry Moore wrote:
Yes. But he does state it is a read only not modified array. My understanding is. 'Array' is an NSMutableArray, I was merely suggesting using freeze to throw that exception just in case there maybe some code attempting to write/modify.
Mutex is the way to go but it also has an overhead.
Didn't somebody (Ernie?) already post a set of mix-ins for the mutable object classes that used a per-object GCD queue to serialize operations against the object? If the mail archives were easier to search, I'd pull it up, but it isn't and I'm too lazy. :)
- Jordan
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
-- Dr. Sven A. Schmidt abstracture GmbH & Co. KG Wilhelm-Theodor-Römheld-Straße 28 55130 Mainz Fon +49 6131 696 29 0 Fax +49 6131 696 29 29 Mail sas@abstracture.de Amtsgericht Mainz HRA 40625 USt-IdNr.: DE258454694 Persönlich haftender Gesellschafter: abstracture IT-Beratungs- und Beteiligungsgesellschaft mbH, Sitz Mainz, Amtsgericht Mainz HRB 41357 Geschäftsführer: Dr. U. Koch, T. Meyer, A. Misok, Dr. S.A. Schmidt, Dr. V. Schönharting
Hmm thanks, I didn't realize we had a google groups mirror. I'm wondering if we shouldn't just move there since it's much easier to use and maintain than macosforge. Thoughts, ideas, suggestions? - Matt On Thu, Oct 20, 2011 at 12:13 AM, Sven A. Schmidt <sas@abstracture.de>wrote:
I found that searching the google groups mirror was much easier and this might be the thread you're referring to:
https://groups.google.com/d/topic/macruby/ceyNNqComMc/discussion
-sas
On Oct 19, 2011, at 22:43, Jordan K. Hubbard wrote:
On Oct 19, 2011, at 11:38 AM, Terry Moore wrote:
Yes. But he does state it is a read only not modified array. My
understanding is. 'Array' is an NSMutableArray, I was merely suggesting using freeze to throw that exception just in case there maybe some code attempting to write/modify.
Mutex is the way to go but it also has an overhead.
Didn't somebody (Ernie?) already post a set of mix-ins for the mutable object classes that used a per-object GCD queue to serialize operations against the object? If the mail archives were easier to search, I'd pull it up, but it isn't and I'm too lazy. :)
- Jordan
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
--
Dr. Sven A. Schmidt abstracture GmbH & Co. KG Wilhelm-Theodor-Römheld-Straße 28 55130 Mainz
Fon +49 6131 696 29 0 Fax +49 6131 696 29 29 Mail sas@abstracture.de
Amtsgericht Mainz HRA 40625 USt-IdNr.: DE258454694
Persönlich haftender Gesellschafter: abstracture IT-Beratungs- und Beteiligungsgesellschaft mbH, Sitz Mainz, Amtsgericht Mainz HRB 41357
Geschäftsführer: Dr. U. Koch, T. Meyer, A. Misok, Dr. S.A. Schmidt, Dr. V. Schönharting
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On 19 Oct 2011, at 22:43, Jordan K. Hubbard wrote:
If the mail archives were easier to search, I'd pull it up, but it isn't and I'm too lazy. :)
I set up an entry in gmane for the mailing list a while ago in order to search the list a bit better: http://news.gmane.org/gmane.comp.lang.ruby.macintosh.devel
Just a note to the original question.... macruby collections are based on objc mutable collections...e.g. a = %w{my array of strings} ["my","array","of"strings"] b = a.dup. b is still a mutable array. c = NSarray.alloc.initWithArray( a ) immutable array c << "hi" runtime error cannot modify frozen/iimmutable array b= a.dup.freeze b << "hi" behaves the same way as NSArray an immutable array....... Terry On 21/10/2011, at 9:00 AM, Andy Park wrote:
On 19 Oct 2011, at 22:43, Jordan K. Hubbard wrote:
If the mail archives were easier to search, I'd pull it up, but it isn't and I'm too lazy. :)
I set up an entry in gmane for the mailing list a while ago in order to search the list a bit better:
http://news.gmane.org/gmane.comp.lang.ruby.macintosh.devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Thanks, I am using: results = NSArray.arrayWithArray(worker_results) which although it reports true for is_a?(NSMutableArray) is immutable. Cheerio, Michael Johnston lastobelus@mac.com On 2011-10-20, at 3:47 PM, terl wrote:
Just a note to the original question....
macruby collections are based on objc mutable collections...e.g.
a = %w{my array of strings} ["my","array","of"strings"]
b = a.dup. b is still a mutable array.
c = NSarray.alloc.initWithArray( a ) immutable array
c << "hi"
runtime error cannot modify frozen/iimmutable array
b= a.dup.freeze
b << "hi"
behaves the same way as NSArray an immutable array.......
Terry
On 21/10/2011, at 9:00 AM, Andy Park wrote:
On 19 Oct 2011, at 22:43, Jordan K. Hubbard wrote:
If the mail archives were easier to search, I'd pull it up, but it isn't and I'm too lazy. :)
I set up an entry in gmane for the mailing list a while ago in order to search the list a bit better:
http://news.gmane.org/gmane.comp.lang.ruby.macintosh.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
That's odd. I would still use freeze more rubyish... :) Terry Moore On 22/10/2011, at 6:41 PM, Michael Johnston <lastobelus@mac.com> wrote:
Thanks, I am using:
results = NSArray.arrayWithArray(worker_results)
which although it reports true for is_a?(NSMutableArray) is immutable.
Cheerio,
Michael Johnston lastobelus@mac.com
On 2011-10-20, at 3:47 PM, terl wrote:
Just a note to the original question....
macruby collections are based on objc mutable collections...e.g.
a = %w{my array of strings} ["my","array","of"strings"]
b = a.dup. b is still a mutable array.
c = NSarray.alloc.initWithArray( a ) immutable array
c << "hi"
runtime error cannot modify frozen/iimmutable array
b= a.dup.freeze
b << "hi"
behaves the same way as NSArray an immutable array.......
Terry
On 21/10/2011, at 9:00 AM, Andy Park wrote:
On 19 Oct 2011, at 22:43, Jordan K. Hubbard wrote:
If the mail archives were easier to search, I'd pull it up, but it isn't and I'm too lazy. :)
I set up an entry in gmane for the mailing list a while ago in order to search the list a bit better:
http://news.gmane.org/gmane.comp.lang.ruby.macintosh.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
Thanks. Since there are a lot of options I'm going to do a benchmark to compare them. For my particular workload, the problem is a "changing gears" sort of problem, where I need to collect an aggregate result to the ui. Since the worker loop is pretty consistent in the time each iteration takes, but results are random, I will test the idea of using a lazy lock, where the worker collects results in an array only the worker accesses and dumps them to the array the UI updater can access every X times through the loop (or by time, if that benchmarks better). Cheerio, Michael Johnston lastobelus@mac.com On 2011-10-19, at 8:28 AM, Matt Aimonetti wrote:
The proper way to protect mutable objects is to use a mutex: http://www.ruby-doc.org/core-1.9.2/Mutex.html
- Matt
Sent from my iPhone
On Oct 19, 2011, at 8:06, Chuck Remes <cremes.devlist@mac.com> wrote:
On Oct 19, 2011, at 12:41 AM, Terry Moore wrote:
If you're not wring/changing the array no problems. But to be safe use Object#freeze...
Terry Moore
On 19/10/2011, at 6:26 PM, Michael Johnston <lastobelus@mac.com> wrote:
Note, in my example I can also guarantee that none of the elements in b are going to be changed (for example, an array of strings)
Object#freeze is a terrible method. Supporting it requires an extra check (#frozen?) in every method that tries to modify an object. This is why Ruby is slow (certainly not the only reason, but decisions like this are everywhere).
:)
Using #freeze won't save you but it will throw a RuntimeException if you try to modify a frozen object. So it's really only good for pointing out that you have a bug when you attempt to modify your immutable array.
cr
_______________________________________________ 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
participants (8)
-
Andy Park
-
Chuck Remes
-
Jordan K. Hubbard
-
Matt Aimonetti
-
Michael Johnston
-
Sven A. Schmidt
-
terl
-
Terry Moore