threading question, are ops on builtins atomic?

[Sam Roberts]

Can I do Array#push from multiple threads at the same time, and know
that all the objs pushed from the threads are on the Array, in some
indeterminate order? What about Array#delete from multiple threads,
and know it was deleted (though only by one of the threads)?

Can I do Socket#recvfrom and Socket#sendto from multiple threads?

I think the answers should be yes, because ruby threads aren't real
threads, they are more mechanisms for dealing with blocking operations
(like socket calls and explicit Mutex) than threads.

I don't want to start peppering my code with unnecessary
Mutex#synchronize calls!

Cheers,
Sam

 

[Florian Gross]

Can I do Array#push from multiple threads at the same time, and know
that all the objs pushed from the threads are on the Array, in some
indeterminate order? What about Array#delete from multiple threads,
and know it was deleted (though only by one of the threads)?

AFAIK yes, because there are usually no Ruby thread context switches in
C functions. But note that += and friends are not atomic.

 

[Charles Mills]

AFAIK yes, because there are usually no Ruby thread context switches in
C functions. But note that += and friends are not atomic.

Is / will this be the case when using pthreads?
in Ruby 2.0?

-Charlie

 

[Yukihiro Matsumoto]

Hi,

In message "Re: threading question, are ops on builtins atomic?"

|Is / will this be the case when using pthreads?
|in Ruby 2.0?

No.

matz.

 

[Glenn Parker]

|Is / will this be the case when using pthreads?
|in Ruby 2.0?

No.

Matz, could you please elaborate just a little bit? I *think* what you
are saying is that operations like Array#delete will *not* be atomic
under pthreads, but it's hard to tell. So, I will try asking again.

What sorts of operations, if any, will be implicitly atomic under pthreads?

 

[Charles Mills]

Matz, could you please elaborate just a little bit? I *think* what you
are saying is that operations like Array#delete will *not* be atomic
under pthreads, but it's hard to tell. So, I will try asking again.

I imagine making operations atomic under pthreads is difficult to
implement (and slow) since Ruby cannot control the context switching
(or at least to the degree it can now using its own thread
implementation), so everything would have to use its own locking
scheme.

What sorts of operations, if any, will be implicitly atomic under

pthreads?

Good question. I assume IO would by one, since when you compile with
pthreads most C stdlibs make stdio functions thread safe, but then I
think ruby 2.0 will not be using stdio. (Maybe this is partly to
ensure IO functions are thread safe?)
....rambling...

-Charlie

 

[Yukihiro Matsumoto]

Hi,

In message "Re: threading question, are ops on builtins atomic?"

|> |Is / will this be the case when using pthreads?
|> |in Ruby 2.0?
|>
|> No.
|
|Matz, could you please elaborate just a little bit? I *think* what you
|are saying is that operations like Array#delete will *not* be atomic
|under pthreads, but it's hard to tell. So, I will try asking again.

It's hard to assure what would be atomic under the pthread
environment, because atomicity changes for each implementation of
pthread. So the most exact answer would be "no, there's no assured
atomic operation without explicit semaphore".

matz.