Re: [ANN] coThreads 0.10

[Zheng Li <li@pps.jussieu.fr>]

Hi,

Thanks skaller for testing the fix on his machine. Here is a few updates:

 - I chose the simple fix: just restrict the upper bound of fresh_number
   based on the word_size of 32bit machine. It's only used to generate fresh
   number, name and offset, so I suspect the range is fairly enough. On the
   other hand, it won't be difficult to make use int64 and LargeFile for 64bit
   machine if necessary, but I'd better to get some x64 machine around for
   testing first.

 - A README for /example is added (also attached to the end of this post) 

 - Some minor updates to a few examples

 - I have no idea what's wrong with the sourceforge file download system. It
   did work when I uploaded the file a few days ago. Anyway, I re-uploaded the
   package (with the above modifications), hope it works.

Best regards.

-- 
Zheng Li
http://www.pps.jussieu.fr/~li


README for examples
===================

== BUILD ==

Just ''make all'' after you've got coThreads installed on your system.
Type ''make clean'' to remove all imtermediate and final building results.

== LIST ==

* coth (use: Thread (or Cothread), Mutex)
  Simple test of mutex. A set of threads tries to grab a single mutex and
  release it for random times 

* evt (use: Thread (or Cothread), Event)
  Simple test of event. Most examples are directly from the OCaml OReilly
  book. The execution won't exist, this is intentional.

* lock (use: Thread (or Cothread), Mutex)
  Simple test of mutex. A set of threads try to grab two mutex. Each thread
  first must grab the first mutex before the second mutex, then release the
  second mutex and the first one.

* mcast (use: Thread (or Cothread), Stm)
  STM example from [1], contributed by Yoriyuki Yamagata

* merge (use: Thread (or Cothread), Stm)
  STM example from [1], contributed by Yoriyuki Yamagata

* mvar (use: Thread (or Cothread), Stm)
  STM example from [1], contributed by Yoriyuki Yamagata

* phil (use: Thread (or Cothread), Stm)
  Classical philosophers dinning problem written in STM. Launch it with 
  [./phil n], where n is the number of philosophers and chopsticks.

* ray_col, ray_nocol (use: Cothread, Event)
  Replanted versions of Jon Harrop's ray tracer [3]. ray.ml is the module
  containing common computation functions, ray_xxx.ml are parallel engines.
  In ray_nocol.ml, the workers don't send the results back to master, instead
  they write them directly to the output file; in ray_col.ml, the workers send
  results back to the master, and the master write them to the output file. 
  Launch it with [./ray_xxx level size degree outputfile], where [level] and
  [size] are about the quality of output image, and [degree] is the parallel
  degree which should equal or greater than the cores or cpus of your machine
  if you'd like to get the most speedup. Or you may just lanch it with
  [./ray_xxx] which takes the default setting [./ray_xxx 9 512 2 ray_xxx.pgm]

* santa (use: Thread (or Cothread), Stm)
  The Santa Clause problem documented in [2]. The haskell version is attached
  as comment at the end of the file.

* sing (use: Thread (or Cothread), Stm)
  Simple test of Stm. Two threads constantly update a single tvar.

* test (use: Thread (or Cothread), Stm)
  Simple test of Stm to calculate the sum of [0..n-1] with n threads. The i_th
  thread is responsible for adding i to the sum. Its action is not allowed to
  take place until the current sum exceed sum (i/10).

* The Makefile itself is an example. It shows that how you can build your
  applications against a set of execution engines with just a few lines of
  pattern rules.

[1] http://research.microsoft.com/users/simonpj/papers/stm/index.htm#composble
[2] https://research.microsoft.com/users/simonpj/papers/stm/index.htm#beautiful
[3] http://www.ffconsultancy.com/languages/ray_tracer/index.html


Zheng Li <li@pps.jussieu.fr> writes:
> Thank you for the bug report. 
>
> Unfortunately I don't have a x64 machine to test, and know quite little about
> 64bit machine (that's why I made the mistake). 
>
> But the bug reason seems obvious: on a x64 machine, one have to use
> Unix.LargeFile.lseek to seek the address in the extra space. 
>
> On the other hand, I think 2^14 locks (the x86 case) are fairly enough in
> most situation. So we don't have to bother with Int64 and LargeFile. Could you
> (or anyone else with a x64 machine) help to test the simple solution: change
> "Sys.word_size - 2"  in the definition of "fresh_number" to 
> "(min Sys.word_size 32) - 2" as follows
>
> let fresh_number =
>   let usable_size = (min Sys.word_size 32) -2 in
>   let bits_of_id = 16 in (* Should be sufficient in most OS *)
>   ........
>
> and report whether it works? Thanks