[toronto-lisp] April meeting minutes available on the website

Vishvajit Singh vishvajitsingh at gmail.com
Tue Apr 14 14:57:54 UTC 2009

Thanks Mike! Those papers answer a lot of my questions.

I would love to learn more about this stuff.. I think I'll head off to
Chapters today and see if I can find a good book on concurrency.


On Tue, Apr 14, 2009 at 8:46 AM, Michael DiBernardo <mikedebo at gmail.com> wrote:
> Papers #4 and #6 on this page:
> http://www.cs.ubc.ca/~norm/508/2007W1/readinglist.html
> might help out those of us who aren't well-versed in the debate
> between event-based and thread-based concurrency. A lot of the topics
> that are coming up in this thread have been discussed (and discussed
> and discussed and...) in O/S-related literature for a looong time :)
> -Debo
> On Mon, Apr 13, 2009 at 10:57 PM, Vishvajit Singh
> <vishvajitsingh at gmail.com> wrote:
>> Thanks for the clarification, Doug. I see that your opinion is more
>> nuanced than the version I put up. I'll update it soon and put up a
>> more accurate version of your opinion.
>> Rich Hickey's ant simulation is a good case study for Clojure
>> concurrency in action. You may find it interesting to read through:
>> http://clojure.googlegroups.com/web/ants.clj
>> It will take me some time to fully work through your arguments, as I
>> haven't worked very much with concurrency myself. How do you feel your
>> opinions hold up on the issue of simple convenience for the
>> programmer? I mean, using select() for IO, fork() for concurrency, and
>> Berkeley DB for transactions throughout your programs takes extra
>> effort as compared to using the built-in language mechanisms. In the
>> case of the ant colony simulation, you'd have to worry about the
>> problem of distributing the ants among N forked processes, where N is
>> the number of processors, whereas if you use shared-memory threads,
>> you let the OS handle that.
>> Regards,
>> Vish Singh
>> On Mon, Apr 13, 2009 at 7:20 PM,  <doug at hcsw.org> wrote:
>>>> We discussed Clojure's concurrency mechanism (Software Transactional Memory).. Doug wonders whether it is overkill to include such a complex mechanism built-in to the language. Much disagreement here among the members.
>>> I have never used Clojure so I can't comment much about it
>>> specifically, but that is not what I said about concurrency.
>>> Let me elaborate again:
>>> Before you use threads (by which I mean pre-emptively scheduled,
>>> shared memory processes) ask yourself why:
>>> * To handle multiple streams of IO? Solution: Schedule one
>>>  process to handle all the IO by using an event API like select(),
>>>  non-pre-emptively scheduled threads like GNU pth
>>>  (http://www.gnu.org/software/pth/), or "coroutines", "green threads",
>>>  whatever you wanna call em.
>>> * To take advantage of multiple CPUs or multiple disks?
>>>  Solution: Learn how the fork() system call works and use
>>>  sockets or pipes for message passing.
>>> To me there is no reason to ruin a great language like Common Lisp
>>> with thread-related non-determinism. I think having to ban mutable
>>> data structures from your language as in Clojure is a symptom of
>>> a poor concurrency strategy. As I said at the meeting, in my opinion
>>> the best implementation of transactional memory is Berkeley DB:
>>> * Clojure's memory isn't persistent so if your application
>>>  crashes or the power goes out you will lose all your memory.
>>>  BDB can persist the memory to disk guaranteeing transactional
>>>  consistency (although this is optional).
>>> * As far as I know, Clojure transactional memory can only be
>>>  accessed by threads running in the same process. BDB DBs are
>>>  multi-process AND multi-thread.
>>> * BDB allows replication so that the memory is distributed to
>>>  physically separate machines. Each will have a transactionally
>>>  consistent view of the data.
>>> * BDB DBs can be larger than your address space on 32 bit systems.
>>>  I'd guess that Clojure's transactional storage is limited on such
>>>  systems.
>>> * BDB hotbackups let you snapshot a DB without interrupting
>>>  anything. I use the included db_hotbackup utility.
>>> * BDB DBs can be accessed by programs in any language: Perl,
>>>  Common Lisp, C, etc. Probably from Clojure too.
>>> _______________________________________________
>>> toronto-lisp mailing list
>>> toronto-lisp at common-lisp.net
>>> http://common-lisp.net/cgi-bin/mailman/listinfo/toronto-lisp
>> _______________________________________________
>> toronto-lisp mailing list
>> toronto-lisp at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/toronto-lisp

More information about the toronto-lisp mailing list