Skip to main content

Carlos Santos's Library tagged concurrency   View Popular

20 Jun 09

Amazon.com: Clojure Bookshelf

R. Hickey (clojure author): "Books that influenced clojure". Besides the obvious ones (CTM, SICP) nice to see the Bratko book on Prolog, very good indeed.

www.amazon.com/...ref=cm_lm_byauthor_title_full - Preview

via:chl books clojure programming concurrency

21 Apr 09

Making it stick.: Learning from Mistakes — A Comprehensive Study on Real World Concurrency Bug Characteristics

Some of our findings are as follows: (1) Around one third of the examined non-deadlock concurrency bugs are caused by violation to programmers’ order intentions, which may not be easily expressed via synchronization primitives like locks and transac- tional memories; (2) Around 34% of the examined non-deadlock concurrency bugs involve multiple variables, which are not well addressed by existing bug detection tools; (3) About 92% of the examined concurrency bugs can be reliably triggered by enforcing certain orders among no more than 4 memory accesses. This indi- cates that testing concurrent programs can target at exploring possi- ble orders among every small groups of memory accesses, instead of among all memory accesses; (4) About 73% of the examined non-deadlock concurrency bugs were not fixed by simply adding or changing locks, and many of the fixes were not correct at the first try, indicating the difficulty of reasoning concurrent execution by programmers.

patricklogan.blogspot.com/...om-mistakes-comprehensive.html - Preview

concurrency bugs paper programming

  • Some of our findings are as follows: (1) Around one third of
    the examined non-deadlock concurrency bugs are caused by violation to programmers’ order intentions, which may not be easily
    expressed via synchronization primitives like locks and transac-
    tional memories; (2) Around 34% of the examined non-deadlock
    concurrency bugs involve multiple variables, which are not well
    addressed by existing bug detection tools; (3) About 92% of the
    examined concurrency bugs can be reliably triggered by enforcing
    certain orders among no more than 4 memory accesses. This indi-
    cates that testing concurrent programs can target at exploring possi-
    ble orders among every small groups of memory accesses, instead
    of among all memory accesses; (4) About 73% of the examined
    non-deadlock concurrency bugs were not fixed by simply adding
    or changing locks, and many of the fixes were not correct at the
    first try, indicating the difficulty of reasoning concurrent execution
    by programmers.
1 - 20 of 89 Next › Last »
Showing 20 items per page

Diigo is about better ways to research, share and collaborate on information. Learn more »

Join Diigo