Threading question, are ops on builtins atomic?

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

Sam Roberts wrote:

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.

Florian Gross wrote:

Sam Roberts wrote:

> 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.

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

-Charlie

Hi,

···

In message "Re: threading question, are ops on builtins atomic?" on Tue, 8 Feb 2005 09:30:09 +0900, "Charles Mills" <cmills@freeshell.org> writes:

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

No.

              matz.

Yukihiro Matsumoto wrote:

"Charles Mills" <cmills@freeshell.org> writes:

>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?

···

--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/&gt;

Glenn Parker wrote:

Yukihiro Matsumoto wrote:
> "Charles Mills" <cmills@freeshell.org> writes:
>
> >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.

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

Hi,

···

In message "Re: threading question, are ops on builtins atomic?" on Tue, 8 Feb 2005 22:20:21 +0900, Glenn Parker <glenn.parker@comcast.net> writes:

>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.