cothreads-discuss Mailing List for coThreads

Hi,

Erik de Castro Lopo <mle...@me...> writes:
> Hi all,
>
> I'm not sure how many people are aware of the Wide Finder benchmark:
>
>    http://www.tbray.org/ongoing/When/200x/2007/09/20/Wide-Finder
>
> Currently, the best performing solution is one in JoCaml:
>
>    http://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Results

Yes, I'm aware of that.

> I had been meaning to attempt to covert the JoCaml solution to
> CoThreads for an interesting comparison, but have simply been
> way too busy.

Me too. I haven't got enough time to integrate a few new features to
cothreads yet, though the design was finished a few weeks ago. 

There are also some other consideration which prevent me from writing an
entry:

 - the underlying implementation mechanics of JoCaml and coThreads are
   the same: both using independent processes and the host language is
   OCaml. So I wouldn't expect there will be much difference on
   efficiency between a JoCaml entry and a coThreads entry.

 - The problem is embarrassingly parallel in nature. As long as you have
   a not so shabby high-level parallel library in your language, it
   won't distinguish two much on the parallel language design aspect,
   not even the parallel runtime implementation aspect (given if the
   computation part occupies the most portion of the running
   time). E.g., I won't be surprised if there is a concise and efficient
   C++ entry written in MapReduce etc. In such a case, it
   actually boils down to comparing the efficiency of
   all the hosting language and the algorithm used by the sequential
   computation, rather than their parallel add-on. So it's not
   unexpected that a OCaml entry is currently ranking No.1 among
   language such as PHP, Python, Perl etc. Erlang also achieves some
   good benchmarks, ironically it's not for its parallelism, it's due to
   its newly introduced binary manipulation library!

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

Hi all,

I'm not sure how many people are aware of the Wide Finder benchmark:

   http://www.tbray.org/ongoing/When/200x/2007/09/20/Wide-Finder

Currently, the best performing solution is one in JoCaml:

   http://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Results

I had been meaning to attempt to covert the JoCaml solution to
CoThreads for an interesting comparison, but have simply been
way too busy.

Hopefully this email may prompt somone with a little time on
their hand into contibuting to this rather interesting experiment.

Cheers,
Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"XML is not a language in the sense of a programming language any
more than sketches on a napkin are a language." -- Charles Simonyi

Thanks for answering

On 10/10/2007, zhe...@us...
<zhe...@us...> wrote:

> When I searched "Illegal instruction" through the OCaml mailing list achieve, I
> found that most of this kind of problems are related to OCaml runtime rather
> than user space libries. Especially, I found the bug report [1], which seems to
> be exactly related:
>
> [1] http://caml.inria.fr/mantis/view.php?id=4348&nbn=12

Yes, that could well be it. It was closed yesterday...

> Knowing quite little about the implementation of your application, I would
> predict two problems here:
>
>  - coThreads STM involves taking snapshot of transactional variables (OCaml
>    values). In your case, it seems that the real storage is in C side and the
>    OCaml-side values are just descriptor (possibly unchanged?). So I fail to
>    see what kind of benefit you can get here.

No as I said later on - I don't see I direct match. But for real world
usage STM will in general need to consider "out-of-band" storage -
providing locks is one way to do this, but that does not bring STM
benefits to the table.

>  - I have some experience with Bigarray which is based on mmap. It's unlikely,
...
>    update them independently, the efficiency is dramatically improved. The
>    problem is that, a Bigarray can hardly considered as a set of independently
>    array elements (On the other hand, you can do that, but the most functions
>    are no longer directly applied to Bigarray itself.

Yes - that is not exactly what I'm doing, but the concept is not that
different. You can define a set of atomic low-level operations on the
storage and coordinate these.

I guess coThreads actually could use a "rollback" trigger operation so
it doesn't just roll back a TVar but triggers external rollback in
that case. For example, you could register "appended x bytes to pos y"
in a TVar taking up limited of space and undo the operation without
storing a full log, or you could link it to an SQL server transaction.

>    You can actually read
>    Bigarray values into OCaml values and operate on OCaml values then write the
>    result back as Bigarray values, however I'm not sure if this is what you want)

Unless only small amounts are modified, that would load the ocaml heap
too much, but in some cases it might make sense - such as making
invariants over control elements guarding access to the rest of the
data. This is a kind of name based locking where name lookup is needed
so other threads can find a loaded copy. An STM hash table would be
one way to do this - might be convenient across processes compared to
alternatives like a hash table with a pool of recycled mutexes.

> > I'm fairly sure STM can't be used directly for my storage although
> > some principles are related, but it might solve my need for higher
> > level concurrency control including process coordination and provide
> > atomic operations on lower level structures.
> Considering your application, there are also traditional mutex and condition
> modules in the process engine, compatible with the standard ones for
> threads/vmthreads. On the other hand, you shouldn't have much difficult to
> implement your own control structure in term of STM.

Right - it's mostly about having a convenient abstraction to work with.

> I'm currently working on the following extensions for coThreads:
>
>   - special thread identifier: Cothread.anyone and Cothread.everyone
>   - raise exception in certain thread(s): raise_in
>   - Timer module: set timer, schedule and timeout
>   - Lock module: fine-grained reader/writer locks

Keep up the good work.

> > btw.: the web menu is broken on this page:
> > http://cothreads.sourceforge.net/example/index
> It's a problem of the sourceforge web hosting. Usually it works again if you
> reload the page.

Working again.


> I also CC the reply to coThreads mailing list, hope you don't mind.

OK

Mikkel

Hi,

"Mikkel Fahn=F8e J=F8rgensen" <mik...@gm...> writes:
> coThreads looks interesting!
Glad to hear :)

> I tried the raytracer example on OS-X - but ray_nocol.nath.opt and
> ray_col.nath.opt immediately results in "Illegal Instruction".
> .proc.opt and .nath (bytecode) works.
I'm totally alien to Mac and don't have a testing environment at hand. Howe=
ver,
the two ray* programs don't make much use of the coThreads extension, most
parts of them are written in plain OCaml (spawn* functions are actually a e=
vent
wrapper).=20

When I searched "Illegal instruction" through the OCaml mailing list achiev=
e, I
found that most of this kind of problems are related to OCaml runtime rather
than user space libries. Especially, I found the bug report [1], which seem=
s to
be exactly related:

[1] http://caml.inria.fr/mantis/view.php?id=3D4348&nbn=3D12

> Another question:
>
> I'm not sure how coThreads will interact with memory mapped files, backgr=
ound:
>
> I am working a mmap based storage written in C, linked to OCaml where
> I'm actually about to do something related with transactional memory,
> primarily for crash recovery (as in: data not modified by other
> thread, but by inconsistent disk write) and possibly also for
> multicore operation. Here the mmap image is a mostly up to date
> representation and the transaction log is the authoritative storage.
>
> If I used coThreads with proc, I assume I will either get a shared r/w
> view of the mapped file - but I guess it both depends on how I create
> the mmap and how the process is spawned?

Knowing quite little about the implementation of your application, I would
predict two problems here:

 - coThreads STM involves taking snapshot of transactional variables (OCaml
   values). In your case, it seems that the real storage is in C side and t=
he
   OCaml-side values are just descriptor (possibly unchanged?). So I fail to
   see what kind of benefit you can get here.

 - I have some experience with Bigarray which is based on mmap. It's unlike=
ly,
   in this model, to consider each array element as independent OCaml value=
. So
   with STM, there is an efficiency problem here: if we declare the whole a=
rray
   as one transactional variable, the update of any element inside the array
   will lead to the update of the whole array hence inefficient; instead, i=
f we
   take the elements inside the array as a set of transactional variables a=
nd
   update them independently, the efficiency is dramatically improved. The
   problem is that, a Bigarray can hardly considered as a set of independen=
tly
   array elements (On the other hand, you can do that, but the most functio=
ns
   are no longer directly applied to Bigarray itself. You can actually read
   Bigarray values into OCaml values and operate on OCaml values then write=
 the
   result back as Bigarray values, however I'm not sure if this is what you=
 want)
>
> Are you considering how to get processes working with Windows?
For now, the coThreads implementation depends on some *nix only system calls
such as pipe, so I wouldn't expect it to work on Windows at the
moment. However, it's possible to substitute them with other Windows
workarounds in the future.
>
> I'm fairly sure STM can't be used directly for my storage although
> some principles are related, but it might solve my need for higher
> level concurrency control including process coordination and provide
> atomic operations on lower level structures.
Considering your application, there are also traditional mutex and condition
modules in the process engine, compatible with the standard ones for
threads/vmthreads. On the other hand, you shouldn't have much difficult to
implement your own control structure in term of STM.=20

I'm currently working on the following extensions for coThreads:

  - special thread identifier: Cothread.anyone and Cothread.everyone
  - raise exception in certain thread(s): raise_in
  - Timer module: set timer, schedule and timeout
  - Lock module: fine-grained reader/writer locks

> Network operation would be interesting, no so much for immutable data
> access, but rather as a means to coordinate heterogene cooperating
> processes such as a db drive, a db transaction logger and a cache
> server. This could happen through low bandwidth shared mutable data.
Sounds nice.

> btw.: the web menu is broken on this page:
> http://cothreads.sourceforge.net/example/index
It's a problem of the sourceforge web hosting. Usually it works again if you
reload the page.

I also CC the reply to coThreads mailing list, hope you don't mind. You may
also consider joining it if interested.

All the best
--=20
Zheng Li
http://www.pps.jussieu.fr/~li

Erik de Castro Lopo <mle...@me...> writes:
> Zheng Li wrote:
>
>> 
>> Naming them as "Comutex" "Cocondition" "Coevent" is a bit confusing, since they
>> are not in the same relation as "Cothread" with "Thread" (compatible super set)
>> and the "Co" won't stand for anything in these cases. Naming them as "MutexExt"
>> or "ExtMutex" sounds a bit cumbersome.
>> 
>> Any ideas?
>
> Since these are extensions to existing modules, could you do something like
> ExtString and ExtList modules from ExtLib do to standard String and List
> modules?

Not really. Two problems here:

 - IIRC, ExtList and ExtString are compatible superset of standard List and
   String, just like Cothread with Thread, this is crucial to the "open" trick
   they use (so that ExtList.List will fully cover List). But here we're
   talking about incompatible extensions.
 - Even if it's possible (like in the case of Cothread/Thread), I don't like
   ExtLib's "open trick", which is so implicit that it can confuse people (and
   oneself). That's why I didn't take the same approach to make Cothread module
   as Cothread.Thread.

Anyway, I made up my mind. Because the extended modules are different from the
standard ones in so many aspects (more than I though previously, esp. on the
Event/Future idea), I will give them new names. 

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

Zheng Li wrote:

> 
> Naming them as "Comutex" "Cocondition" "Coevent" is a bit confusing, since they
> are not in the same relation as "Cothread" with "Thread" (compatible super set)
> and the "Co" won't stand for anything in these cases. Naming them as "MutexExt"
> or "ExtMutex" sounds a bit cumbersome.
> 
> Any ideas?

Since these are extensions to existing modules, could you do something like
ExtString and ExtList modules from ExtLib do to standard String and List
modules?

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"A program invented (sic) by a Finnish computer hacker and handed out
free in 1991 cost investors in Microsoft $11 billion (_6.75 billion)
this week." - Andrew Butcher in the UK's Sunday Times, Feb 20th, 1999

Hi,

I'm refining the implementation of Event/process and Condition/process. I ran
into a situation where reader(shared)/writer(exclusive) lock is
wanted. Actually, similar mechanics is already used inside the implementation
of Stm/threads, now it seems that I should do something similar for
process. This led me to think: if it's so frequently used, rather than embedded
them as insider helper, how about provide them as enhanced modules? 

For example, the standard modules can extended in the following ways

  - Mutex: support reader/writer locks
  - Condition: support capacity 
  - Event: support future

What do you think? 

On the other hand, I really have problem in naming them. They are enhanced (but
not compatible) version of the original modules. For example, in the new Mutex
module, ''lock'' function will take a optional variable indicate how the mutex
should be locked (shared or exclusively), this is not compatible with original
''lock''. 

Naming them as "Comutex" "Cocondition" "Coevent" is a bit confusing, since they
are not in the same relation as "Cothread" with "Thread" (compatible super set)
and the "Co" won't stand for anything in these cases. Naming them as "MutexExt"
or "ExtMutex" sounds a bit cumbersome.

Any ideas?

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

Erik de Castro Lopo <mle...@me...> writes:
> Zheng Li wrote:
>> It would be nice to have coThreads into Debian. However, if you haven't got any
>> Debian packaging experience before, coThreads won't be a good candidate as the
>> first step.
> I work for a company that uses a Debian/Ubuntu based Linux distro on our
> embedded machines. I have generated about 10 packages now, some with mixed 
> C and Ocaml, others which include kernel modules that must allow a version 
> of the package to be installed for each installed kernel package.
> So while I don't have much experience doing Debian packaging within the 
> Debian community I do have quite a bit of experience. I'm also already
> on the debian-ocaml-maint mailing list and I'm certainly not shy about 
> asking for advice.
> However, I'm not precious about this. I'll have a stab at this over the
> weekend. If I get stuck I'll be happy to pass it on to someone else.
Go ahead, good luck :)

A few points may help, coThreads make use of the following principles of OCaml:

 - Two physically different mli files will be compiled to identical cmi file,
   as far as they are structurally equal: the signature items and the order of
   these signature items are the same. 

 - It doesn't matter to link objects compiled against different copy of the
   identical cmi

Btw, to persuade ocamlc to believe that a.ml have a explicit interface file
a.mli, you must have both a.cmi and a.mli in current directory, just a.cmi
isn't enough.

HTH.

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

Zheng Li wrote:

> It would be nice to have coThreads into Debian. However, if you haven't got any
> Debian packaging experience before, coThreads won't be a good candidate as the
> first step.

I work for a company that uses a Debian/Ubuntu based Linux distro on our
embedded machines. I have generated about 10 packages now, some with mixed 
C and Ocaml, others which include kernel modules that must allow a version 
of the package to be installed for each installed kernel package.

So while I don't have much experience doing Debian packaging within the 
Debian community I do have quite a bit of experience. I'm also already
on the debian-ocaml-maint mailing list and I'm certainly not shy about 
asking for advice.

However, I'm not precious about this. I'll have a stab at this over the
weekend. If I get stuck I'll be happy to pass it on to someone else.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"There are two kinds of people in the world, those that have children
and those that ARE children". Children are selfish, or more accurately
ego-centric. Children have a very short-sighted view of the world.
Offer a child one lolly now or the whole bag later and before you can
say ''Don't chop the dinosaur Daddy!'', it's in the gob."
-- my friend Scott

Stupid me, forget to CC to the list.

Hi Erik,

Erik de Castro Lopo <mle...@me...> writes:
> Hi all,
> I just thought I'd state that I intend to create a debian package for
> CoThreads and will submit that to the debian-ocaml-maintainers group
> and hopefully use CoThreads as my first package on the way to becoming
> a full Debian Developer.
It would be nice to have coThreads into Debian. However, if you haven't got any
Debian packaging experience before, coThreads won't be a good candidate as the
first step. To achieve the best compatibility with the standard Thread module
in various kinds of situation, the modules and interfaces' organization and
building process is more complicated than usual, say a library with one plain
module. So maybe start with something simpler?

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

Hi all,

I just thought I'd state that I intend to create a debian package for
CoThreads and will submit that to the debian-ocaml-maintainers group
and hopefully use CoThreads as my first package on the way to becoming
a full Debian Developer.

Cheers,
Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
Linux: generous programmers from around the world all join
forces to help you shoot yourself in the foot for free.

Zheng Li wrote:

> Not sure I sent this successfully yesterday, so I send it again. My apology if
> it did appeared already.

No it didn't. This is the first.

> > - The mailing list should be easier to find out about. I only
> > found it after digging around on the wiki and postint two
> > comments to it.
>
> Well, SF provides a set of service. I'm not sure which ones are more convenient
> to use, just try. It's also fine to comment on the wiki, that's what I
> installed the "discussion" plug-in for.

Personally, I find wiki's fine for user geenerated/enhanced documentation,
but pretty poor for discussion. For discussions, web forums are a very 
poor second choice in comparison to a mailing list.
 
> > - I see the license is GPLv2. I was wondering if that could be
> > changed to LGPL with the linking exception like the license for
> > the Ocaml standard library and many other ocaml libraries. This
> > would allow people to use coThreads to write closed source
> > commercial applications using CoThreads in Ocaml.
>
> That's reasonable. I will probably change it since the next release.

Thats great news. Thanks.
 
> Thanks for the suggestions. It's done, but not yet in the distribution, only in
> svn for now. In example directory, you can now ''make all LOCAL=../src'' to
> indicate using the source directory as basis.

Thats a step in the right direction, but I wonder if it isn't better to
just make "LOCAL=../src" the default and anything else an option.

Cheers,
Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Microsoft's biggest weakness is that they still don't realize how
much they suck." -- Paul Graham

Not sure I sent this successfully yesterday, so I send it again. My apology if
it did appeared already.
==============================================================================


Hi Erik and others,

> First off I'd like to say Zheng Li for CoThreads. I've looked at
> JoCaml, CamlP3l and a couple of others concurrency addons for
> Ocaml, and so far CoThreads seems the best (or at least has the
> lowest barrier for entry).
Thanks for the feedback.

> - The mailing list should be easier to find out about. I only
> found it after digging around on the wiki and postint two
> comments to it.
Well, SF provides a set of service. I'm not sure which ones are more convenient
to use, just try. It's also fine to comment on the wiki, that's what I
installed the "discussion" plug-in for.

> - I see the license is GPLv2. I was wondering if that could be
> changed to LGPL with the linking exception like the license for
> the Ocaml standard library and many other ocaml libraries. This
> would allow people to use coThreads to write closed source
> commercial applications using CoThreads in Ocaml.
That's reasonable. I will probably change it since the next release.

> - Currently, the example programs can't be compile unless the
> CoThreads library is installed first. This makes it hard for
> people just having a look to run the examples. It would be much
> nicer if the examples could all link against the libraries in
> the tarball/svn checkout.
Thanks for the suggestions. It's done, but not yet in the distribution, only in
svn for now. In example directory, you can now ''make all LOCAL=../src'' to
indicate using the source directory as basis. However note that we provide 
''make uninstall'' support from the beginning, just in case the complex
dependent relation between coThreads and standard Threads would confuse
people. 

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

Hi all,

First off I'd like to say Zheng Li for CoThreads. I've looked at
JoCaml, CamlP3l and a couple of others concurrency addons for 
Ocaml, and so far CoThreads seems the best (or at least has the
lowest barrier for entry).

A couple of comments:

  - The mailing list should be easier to find out about. I only
    found it after digging around on the wiki and postint two
    comments to it.

  - I see the license is GPLv2. I was wondering if that could be
    changed to LGPL with the linking exception like the license for
    the Ocaml standard library and many other ocaml libraries. This 
    would allow people to use coThreads to write closed source 
    commercial applications using CoThreads in Ocaml. 

  - Currently, the example programs can't be compile unless the 
    CoThreads library is installed first. This makes it hard for 
    people just having a look to run the examples. It would be much
    nicer if the examples could all link against the libraries in 
    the tarball/svn checkout.

Cheers,
Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
Orcad Express 9: "Its a nice demo but I wouldn't want to use it
on a day-to-day basis" -- me