threads

threads

[ygrek]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

Hello,

 let x = Array.make 100 []
 let update i n = x.(i) <- n :: x.(i)
 let read i = x.(i)

 Consider the following scenario: one thread is `update`ing x, another
thread(s) uses only `read`. Is it safe to use these functions without
locking on mutex? 

 I.e. is Array.set atomic? What about updating references (:=) ?

 If I understand correctly these operations require only one cpu
instruction to update one machine word and so should be atomic. Taking
into account "single-cpu affinity" of ocaml program it should be safe
to write such multithreaded code. Is it true?

 Is it safe to assume that ocamlopt won't skip reads/writes to globally
visible memory address using cached value in a register?

-- 
 ygrek
 http://ygrek.org.ua

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [Caml-list] threads

[Philippe Wang]

Hi,

>  let x = Array.make 100 []
>  let update i n = x.(i) <- n :: x.(i)
>  let read i = x.(i)

I don't think you can obtain funny results when you don't put a mutex
on these two specific "update" and "read".
What is sure is that "update" function is not atomic because you have
a value allocation at the right of "<-" (with :: operator), and this
may trigger garbage collection and/or make the scheduler change the
running thread.

What you can be sure with the current official OCaml distribution is
that there won't be at the exact same time both an (<-)operation and a
(.())operation.
But it is actually possible, for instance, for a thread to compute
while another one is simultaneously writing on a socket. So it is
generally not a good idea to count on some operation atomicity to put
or not a mutex lock (well it's good to write some hard-to-debug
code)...

Cheers,

Philippe Wang


On Tue, Sep 8, 2009 at 7:33 PM, ygrek <ygrekheretix@gmail.com> wrote:
> Hello,
>
>  let x = Array.make 100 []
>  let update i n = x.(i) <- n :: x.(i)
>  let read i = x.(i)
>
>  Consider the following scenario: one thread is `update`ing x, another
> thread(s) uses only `read`. Is it safe to use these functions without
> locking on mutex?
>
>  I.e. is Array.set atomic? What about updating references (:=) ?
>
>  If I understand correctly these operations require only one cpu
> instruction to update one machine word and so should be atomic. Taking
> into account "single-cpu affinity" of ocaml program it should be safe
> to write such multithreaded code. Is it true?
>
>  Is it safe to assume that ocamlopt won't skip reads/writes to globally
> visible memory address using cached value in a register?
>
> --
>  ygrek
>  http://ygrek.org.ua
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>



-- 
Philippe Wang
   mail@philippewang.info

Re: [Caml-list] threads

[ygrek]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

On Wed, 9 Sep 2009 01:20:06 +0200
Philippe Wang <philippe.wang.lists@gmail.com> wrote:

> >  let x = Array.make 100 []
> >  let update i n = x.(i) <- n :: x.(i)
> >  let read i = x.(i)
> 
> I don't think you can obtain funny results when you don't put a mutex
> on these two specific "update" and "read".
> What is sure is that "update" function is not atomic because you have
> a value allocation at the right of "<-" (with :: operator), and this
> may trigger garbage collection and/or make the scheduler change the
> running thread.

Yes, that's not a problem.

Thinking that over again it looks like the only issue remaining is the
possibility that compiler can be too smart and cache/reorder memory
operations, but ocamlopt is not of that kind, right?

-- 
 ygrek
 http://ygrek.org.ua

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Threads

[Jonathan Bryant]

I'm confused.  In the documentation on the threads library it says that
the threads implementation is shared time on only a single processor. 
Is that for VM and system threads, or are the POSIX threads able to take
advantage of multiple processors?  I would think they would be able to
because (unless I'm mistaken) they're just wrappers around the C system
calls...

--Jonathan