Hi,
It's been about 5 years since I faced this situation. I'm trying to
link my program against the Thread module. Things go well until I do
the ocamlopt compilation, then it aborts the make with the message:
ocamlfind ocamlopt -thread -o sdsp.opt -package camlp4 -package
threads -packa
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 updati
On Thu, Apr 23, 2009 at 12:37:14AM -0700, David McClain wrote:
> It's been about 5 years since I faced this situation. I'm trying to link
> my program against the Thread module. Things go well until I do the
> ocamlopt compilation, then it aborts the make with the message:
>
> ocamlfind ocamlopt
OMG!! You are a Prince! Thank you so much!
Cheers,
Dr. David McClain
Chief Technical Officer
Refined Audiometrics Laboratory
4391 N. Camino Ferreo
Tucson, AZ 85750
email: d...@refined-audiometrics.com
phone: 1.520.390.3995
web: http://www.refined-audiometrics.com
On Apr 23, 2009, at 00:42,
> It's been about 5 years since I faced this situation. I'm trying to link
my program against the Thread module. Things go well until I do the ocamlopt
compilation, then it aborts the make with the message:
>
> ocamlfind ocamlopt -thread -o sdsp.opt -package camlp4 -package threads
-package unix
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
On Wed, 9 Sep 2009 01:20:06 +0200
Philippe Wang 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 "u
Hello,
I'm trying to write a function (run_guarded) that takes another function
(f), and runs it for some amount of time. If f terminates with value x, then
the result of run_guarded should be Some x, otherwise it should be None.
Here's my implementation using the Thread library:
let run_guarded
Hello,
I would like to read two files in two different threads.
I have made a first version reading the first then the second and it takes
2.8s (native).
I decided to make a threaded version and before any use of thread I realized
that just linking no even using it to the threads library makes m
Hi,
2009/2/16 Rémi Dewitte :
> I guess it might come from GC slowing down thinks here, doesn't it ?
I don't think so. Why do you think it's GC?
> Can ocaml use multiple cores ?
No and as far as I know it's because of GC. ;-)
regards
Miichal
___
Caml-l
On Tue, Apr 13, 2010 at 1:33 PM, Gregory Malecha
wrote:
> It seems like it should work, but it doesn't work if the function f doesn't
> terminate. It seems to be running everything serially. I know that threads
> aren't actually parallel, but I thought they were preemptive in which case
> it seems
You may also be interested in this thread [1].
Daniel
[1] http://groups.google.com/group/fa.caml/browse_thread/thread/9606b618dab79fb5
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archive
Hi Jake,
The documentation for Condition.wait says:
wait c m atomically unlocks the mutex m and suspends the calling process on
the condition variable c. The process will restart after the condition
variable c has been signalled. The mutex m is locked again before wait
returns.
I figured that I
On Tue, Apr 13, 2010 at 11:56 PM, Gregory Malecha wrote:
> Hi Jake,
> The documentation for Condition.wait says:
> wait c m atomically unlocks the mutex m and suspends the calling process on
> the condition variable c. The process will restart after the condition
> variable c has been signalled. T
Philippe Wang writes:
> On Tue, Apr 13, 2010 at 11:56 PM, Gregory Malecha wrote:
>> Hi Jake,
>> The documentation for Condition.wait says:
>> wait c m atomically unlocks the mutex m and suspends the calling process on
>> the condition variable c. The process will restart after the condition
>> v
On Mon, Feb 16, 2009 at 16:28, Michał Maciejewski wrote:
> Hi,
>
> 2009/2/16 Rémi Dewitte :
> > I guess it might come from GC slowing down thinks here, doesn't it ?
> I don't think so. Why do you think it's GC?
>
Bad guess :) !
Any hint why just linking makes things slow ?
>
> > Can ocaml use mu
Which OS (and port, if applicable) are you using?
From: caml-list-boun...@yquem.inria.fr
[mailto:caml-list-boun...@yquem.inria.fr] On Behalf Of Rémi Dewitte
Sent: 16 February 2009 15:33
To: Michał Maciejewski
Cc: caml-l...@inria.fr
Subject: Re: [Caml-list] Threads performance issue.
On
...@yquem.inria.fr] *On Behalf Of *Rémi Dewitte
> *Sent:* 16 February 2009 15:33
> *To:* Michał Maciejewski
> *Cc:* caml-l...@inria.fr
> *Subject:* Re: [Caml-list] Threads performance issue.
>
>
>
>
>
> On Mon, Feb 16, 2009 at 16:28, Michał Maciejewski
> wrote:
&g
2009/2/16 Rémi Dewitte
> Hello,
>
> I would like to read two files in two different threads.
>
> I have made a first version reading the first then the second and it takes
> 2.8s (native).
>
> I decided to make a threaded version and before any use of thread I
> realized that just linking no even
Yaron,
I use a slightly modified version of the CSV library's load_rows . Here is
the main code which is highly imperative style. I might transform it in
purely functional style ?
The main program is :
open Printf;;
open Sys;;
let timed_exec start_message f =
print_string start_message;
let
I have made some further experiments.
I have a functional version of the reading algorithm. I have the original
imperative version of the algorithm.
Either it is linked to thread (T) or not (X). Either it uses extlib (E) or
not (X).
Results are.
XX TX XE TE
Imperativ
On Tue, Feb 17, 2009 at 08:40:11AM +0100, Rémi Dewitte wrote:
> I have made some further experiments.
> I have a functional version of the reading algorithm. I have the original
> imperative version of the algorithm.
> Either it is linked to thread (T) or not (X). Either it uses extlib (E) or
> not
You need to uncomment the line 107 with Thread calls so that it is
effectively linked to threads I think and see the difference !
I will try the profiling !
Rémi
On Tue, Feb 17, 2009 at 09:59, Mark Shinwell wrote:
> On Tue, Feb 17, 2009 at 08:40:11AM +0100, Rémi Dewitte wrote:
> > I have made s
On Tuesday 17 February 2009 08:59:44 Mark Shinwell wrote:
> On Tue, Feb 17, 2009 at 08:40:11AM +0100, Rémi Dewitte wrote:
> > I have made some further experiments.
> > I have a functional version of the reading algorithm. I have the original
> > imperative version of the algorithm.
> > Either it is
Hi,
I would like to create different threads where each thread do some
computation and are subject to different
timeout. Without threads I usually use Unix.alarm with a SIGALARM
handler that just raise a Timeout exception
and everything works fine, but when I try to do something similar with
threa
Hi,
Some time ago I had some problems with threads. I had to make a
traffic lights simulation with cars as a academic project. I decided
to write it using ocaml with graph module and threads for timing
(since thread pausing didn't work in the same thread that the graph
module worked). If I remembe
You'd have the same problem in any other programming language; this is
due to the underlying POSIX model.
The POSIX standard mentions that alarms are global to the process [1].
" There were two possible choices for alarm generation in
multi-threaded applications: generation for the calling thread
On Mon, Oct 26, 2009 at 11:36 AM, Till Varoquaux wrote:
> You'd have the same problem in any other programming language; this is
> due to the underlying POSIX model.
> The POSIX standard mentions that alarms are global to the process [1].
>
> " There were two possible choices for alarm generation
Am Montag, den 26.10.2009, 12:06 -0700 schrieb yoann padioleau:
> On Mon, Oct 26, 2009 at 11:36 AM, Till Varoquaux wrote:
> > You'd have the same problem in any other programming language; this is
> > due to the underlying POSIX model.
> > The POSIX standard mentions that alarms are global to the
Considering that posix signals are not real-time *anyway*, using them
to programme specific treatments per-thread is hmmm... say a nightmare
! Plus I don't quite see how you could eventually have a non-broken
implementation. Gerd Stolpmann emphasized it if I understood well.
One solution would be
On Mon, Oct 26, 2009 at 12:06:18PM -0700, yoann padioleau wrote:
> I want to write a toy program that uses threads and timeouts in an
> easy way. Those threads may make heavy use of CPU or IO, I don't know.
> I just want an easy API for thread and timeout.
>
> To be honest, the problem I have to s
if you have a thread that never allocates any value in the memory heap, then
the thread may prevent the GC from working properly...
2009/6/27 Michał Maciejewski
> Hi,
>
> Some time ago I had some problems with threads. I had to make a
> traffic lights simulation with cars as a academic project
32 matches
Mail list logo
