Threads

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

Re: [Caml-list] Threads

[Christophe Raffalli]

Jonathan Bryant a écrit :

>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...
>
>  
>
No there is a global mutex for caml thread. The only thing you can do is 
have one Caml thread and many C threads running in the same time.

This starts really to be an annoying limitation of the Caml runtime now 
that you can have easily two dual core processors in one machine ... 
(means four CPU)





>--Jonathan
>
>_______________________________________________
>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
>  
>

Re: [Caml-list] Threads

[james woodyatt]

On 11 Jun 2005, at 00:46, Christophe Raffalli wrote:
>
> No there is a global mutex for caml thread. The only thing you can do 
> is have one Caml thread and many C threads running in the same time.
>
> This starts really to be an annoying limitation of the Caml runtime 
> now that you can have easily two dual core processors in one machine 
> ... (means four CPU)

Not for me it isn't-- I gave up cooperative scheduling with Mac OS 9.

Now, when I want concurrent, preëmptive multiprocessing, I call fork(2) 
[and often exec(2)], like Nature intended.  I don't know why you folks 
on Win32 platforms continue to put up with such abominable support for 
POSIX interfaces.


-- 
j h woodyatt <jhw@wetware.com>
that's my village calling... no doubt, they want their idiot back.

Re: [Caml-list] Threads

[Christophe Raffalli]

james woodyatt a écrit :

> On 11 Jun 2005, at 00:46, Christophe Raffalli wrote:
>
>>
>> No there is a global mutex for caml thread. The only thing you can do 
>> is have one Caml thread and many C threads running in the same time.
>>
>> This starts really to be an annoying limitation of the Caml runtime 
>> now that you can have easily two dual core processors in one machine 
>> ... (means four CPU)
>
>
> Not for me it isn't-- I gave up cooperative scheduling with Mac OS 9.
>
> Now, when I want concurrent, preëmptive multiprocessing, I call 
> fork(2) [and often exec(2)], like Nature intended.  I don't know why 
> you folks on Win32 platforms continue to put up with such abominable 
> support for POSIX interfaces.
>
>
Does not depend what you use (Posix, win32 threads etc ...), OCaml does 
not support two threads accessing the memory at the same time.

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