Lea. Parallelism. Erlang 2. Are all stateful Web applications broken? While there are many Web frameworks in the Java™ ecosystem, they all are based, directly or indirectly, on the Servlets infrastructure. The Servlets API provides a host of useful features, including state management through the HttpSession and ServletContext mechanisms, which allows the application to maintain state that persists across multiple user requests. However, some subtle (and largely unwritten) rules govern the use of shared state in Web applications, of which many applications unknowingly fall afoul.
The result is that many stateful Web applications have subtle and serious flaws. Scoped containers The ServletContext, HttpSession, and HttpRequest objects in the Servlet specification are referred to as scoped containers. Each of these has getAttribute() and setAttribute() methods, which store data on behalf of the application. The difference between them is the lifetime of the scoped container. Sessions Listing 1. Threading considerations Threading risks for Web applications.
Actors with Multi-Headed Receive Clauses. The actor model provides high-level concurrency abstractions to coordinate simultaneous computations by message passing. Languages implementing the actor model such as Erlang commonly only support single-headed pattern matching over received messages.In Martin Sulzmann, Edmund S. L. Lam, Peter Van Weert: Actors with Multi-headed Message Receive Patterns.
We propose an extension of the Actor model with receive clauses supporting multi-headed message patterns. Here's a simple example of a market-place actor receive Seller x, Buyer x -> "match found" We employ the combination of multiple messages in a receive pattern and non-linear patterns to test for a matching seller and a buyer. Receive Seller x, Buyer y when x == y -> "match found" The formal details of a such an enriched actor model are described in the above mentioned paper.
Download Available via (look for the actor library among the Concurrency packages) Overview The Haskell-Actor implementation makes use of send. Introduction to lock-free/wait-free and the ABA problem. Python Thread Deadlock Avoidance. Dave Beazley's mondo computer blog. [ One danger of writing programs based on threads is the potential for deadlock--a problem that almost invariably shows up if you happen to write thread code that tries to acquire more than one mutex lock at once. For example: a_lock = threading.Lock() b_lock = threading.Lock() def foo(): with a_lock: ... with b_lock: # Do something ... t1 = threading.Thread(target=foo) t1.start() Code like that looks innocent enough until you realize that some other thread in the system also has a similar idea about locking--but acquires the locks in a slightly different order: def bar(): with b_lock: ... with a_lock: # Do something (maybe) ...
Sure, the code might be lucky enough work "most" of the time. Computer scientists love to spend time thinking about such problems--especially if it means they can make up some diabolical problem about philosophers that they can put on an operating systems exam. Okay, that was easy enough to do, but does it work? Very good. Termite - Project Hosting on Google Code. Beautiful Coroutines: Cooperative Concurrency in Python using Di. Concur.next — My Take. I’ve been trying to avoid editorializing in this “Java-of-concurrency” series. But since people are grumbling about my biases, here are a few notes about how I see things at this (early, I hope) stage in the process. [This is part of the Concur.next series.] Why Me? · I think I’m well-positioned to do this research and write-up.
First of all, I’ve written a bunch of highly concurrent code over the years (Web crawlers, in-memory data-viz database, one specialized network-management database kernel). So I have a bitter personal appreciation for how hard it is to get this stuff right and debug it, and consequently, how unreasonably long it takes to ship robust working code Second, I’m not a language or platform designer, so I don’t really have a horse in this race. Also, I have a nice little sample project around, the Wide Finder. As regards concurrency, I will freely admit, as I start to dig into this, the following biases: Divide and Conquer - Concurrency.next: Wiki: Home. I'm dumping in a ton of concurrency-related links that I've been absorbing, will build a structure for them as I go along. This is on a wiki not my blog because it could benefit from input from more than one person. Problem/Solution Overview Snakes on the Web is a general survey on issues of Web development, but this link is to a section called "Concurrency" which I think is a nice statement of the general problem.
A Survey of Concurrency Constructs is Ted Leung's OSCON 2009 address. Ted follows up in The Cambrian Period of Concurrency. Java Concurrency in Practice by Brian Goetz et al. I haven't read this but everyone says it's the standard reference for thread-centric concurrent-programming issues. Software Transactional Memory by Mark Volkmann. The Landscape of Parallel Computing Research: A View From Berkeley (PDF). Technical Books for Multi-Core Software Developers at software.intel.com, a bibliography of concurrent-programming books. Language Comparisons The multicore crises: Scala vs.
Snakes on the Web. A talk given at PyCon Argentina and PyCon Brazil, 2009. Web development sucks. It’s true: web development, at its worst, is difficult, repetitive, and boring. The tools we have suck. At best, they make web development slightly less painful, but we’re a long way from making web development awesome. The history of web development tools is a history of trying to solve this problem. That’s exactly what I plan to do. To do so, I’ll start with ancient history. A brief, opinionated history of web development In the beginning, TBL invented the Web, and it was good. I like to think of this time as the “Stone Age” of web development, an age characterized by clumsy, difficult tools.
This sucked. And it led to an obvious question: what if we could generate HTML programatically, like from a database or something? And thus was CGI born, and the Bronze Age of the web began. But CGI sucks. So, again, smart people started asking questions. Now, technical revolutions happen organically. What’s next? Scale Halp! Ongoing · Concur.next. Are there any computer programs that you wish were faster? Time was, you could solve that problem just by waiting; next year’s system would run them faster. No longer; Next year’s system will do more computing all right, but by giving you more CPUs, running at this year’s speed, to work with. So the only way to make your program faster is to work with more CPUs.
Bad news: this is hard. Good news: we have some really promising technologies to help make it less hard. The “Java Moment” · On my recent excursion to Japan, I had the chance for a few conversations with Bruce Tate. Thus the analogy. What I’m Up To · I think that right now is a good time to have a run at this problem.
Here’s what I have so far: Who Should Care · The developers, actually; they have a direct incentive in that by doing concurrency well, their apps will run faster, and their employers do too in that the same performance level will require less iron. LinkedBlockingDeque Performance. Python Thread Synchronization Primitives : Not Entirely What You. Dave Beazley's mondo computer blog. [ If you have done any kind of programming with Python threads, you are probably familiar with the basic synchronization primitives provided by the threading module. Specifically, you get the following kinds of synchronization objects to work with: Lock.
Mutual exclusion lock that's commonly used to protect shared data structures. RLock. Knowing how and when to use the various synchronization primitives is often a non-trivial exercise. Instead, I'd like to look at the inner workings of Python's thread synchronization primitives. A Curious Fact If you write threaded programs, you should know that Python uses real system-level threads to carry out its work. This fact may surprise experienced programmers.
Some History Python has included support for threads for most of its history. Part of the problem faced by early versions of Python was the fact that thread programming interfaces weren't always available or standardized across systems. Semaphores vs. Schemik - data-parallel Scheme. The Little Book of Semaphores.
Allen B. Downey Download the book in PDF now! The video Watch an introduction to semaphores (and Free Books) I presented at Northeastern University: The book The Little Book of Semaphores is a free (in both senses of the word) textbook that introduces the principles of synchronization for concurrent programming. In most computer science curricula, synchronization is a module in an Operating Systems class. The approach of this book is to identify patterns that are useful for a variety of synchronization problems and then show how they can be assembled into solutions.
The book covers the classical problems, including "Readers-writers," "Producer-consumer", and "Dining Philosophers. " Second edition! The second edition of the book is now available in Postscript and PDF. In addition, the LaTeX source code is available in a tar file. Please send comments and corrections to semaphores{at}greenteapress{dot}com. Example code Other Free Books From Green Tea Press:
Is There Any Correct Java Code Out There? OK, the title of this post is intentional hyperbole. Obviously there is correct Java code, even a lot, but I have a feeling it might be a statistically negligible fraction of the total. How can I make such an extreme claim? Well, it all comes back to the Java Memory Model , and how it conflicts with most people's intuitive idea of what happens "in the computer" when their code is running. Now, lest I be accused of unfairly criticizing Java, let me make it clear that I understand Java was the first widespread language that even tried to provide a consistent, accessible and environment for writing multithreaded code.
And that's hard. But even those of us who are working in recent Java environments, with their more forgiving and predictable memory model, still get a lot wrong, and we've been blissfully unaware of it. This quotation is from the abstract of a talk he's giving later this month. And it's as if we were set up for failure. So I did. Symmetric Multiprocessing in Allegro CL. This document contains the following sections: 1.0 Symmetric Multiprocessing introduction 1.1 Loading smp-related functionality 1.2 An example of the difference between SMP Lisp and non-SMP Lisp 1.3 Non-SMP images on platforms that support SMP2.0 Deprecated macros 2.1 Deprecated macro: excl::atomically 2.2 Deprecated macro: without-interrupts 2.3 Deprecated macro: sys:without-scheduling3.0 New macros and related functionality 3.1 Non-synchronizing usages 3.2 Atomic read-modify-write primitives 3.3 Concurrency control for shared objects 3.4 Sharable locks 3.5 The barrier API 3.6 Queues 3.7 Condition Variables4.0 Safe and unsafe operators 4.1 Unsafe standard Lisp operations: *features*, *modules*, require/provide, external-format loading, etc. 4.2 Suspending all processes5.0 Ensuring code is not loaded into an SMP Lisp 1.0 Symmetric Multiprocessing introduction This document describes the Symmetric Multiprocessing (SMP) implementation in Allegro CL on certain platforms.
(excl::atomically . What's Wrong with the Thread Object. I started writing a post about implementing actors in D when I realized that there was something wrong with the way thread spawning interacts with data sharing. Currently D’s class closely mimics its Java counterpart, so I started wondering if this may be a more general problem–a problem with mixing object-oriented paradigm with multithreading. In functional languages like Erlang or Concurrent ML, you start a thread by calling a function– or , respectively.
The argument to this function is another function–the one to be executed in a new thread. If you think of a new thread as a semi-separate application, the thread function is its “main”. You may also pass arguments to it–the equivalent of , , only more general. Those arguments are, of course, passed by value (we’re talking functional programming after all). In non-functional languages it’s possible and often desirable to share data between threads. But there’s more: A in Java has a thread function. Here’s how I see it: Like this: Real-World Concurrency. Related Content Proving the Correctness of Nonblocking Data Structures So you've decided to use a nonblocking data structure, and now you need to be certain of its correctness.
How can this be achieved? When a multithreaded program is too slow because of a frequently acquired mutex, the programmer's typical reaction is to question whether this mutual exclusion is indeed required. Browse this Topic: Favorite Tweets by @ACMQueue Queue on Reddit Real-world Concurrency Chances are you won’t actually have to write multithreaded code. Bryan Cantrill and Jeff Bonwick, Sun Microsystems Software practitioners today could be forgiven if recent microprocessor developments have given them some trepidation about the future of software.
As practitioners who have long been at the coal face of concurrent systems, we hope to inject some calm reality (if not some hard-won wisdom) into a discussion that has too often descended into hysterics. Some Historical Context Concurrency is for Performance. 10 Ideas. Published in 1991 Prelude "Show me. " John held up the chalk, holding it by the top, the bottom pointed at his feet. His smile was slight but visible, visible to everyone in the lecture hall; his smile was aimed at me. Who was more scared, the students, or me - the TA? That’s something no one can ever know, but there were 50 of them and one of me; if my answer is wrong, their answers would have been wrong. Three months earlier, in my first quarter as graduate student at Stanford, in the Lab at the top of the hill, just before a volleyball game, I asked John McCarthy - the John McCarthy - whether I could have an office at the Lab and be supported by it.
"Sure," if I TAed 206, the Lisp course. Some call his classes "Uncle John’s Mystery Hour," in which John McCarthy can and will lecture on the last thing he thought of before rushing late through the door and down the stairs to the front of the lecture hall. So now you’re thinking that the problem was stated funny. "Nah. Introduction Samefringe. Volatile Arrays in Java. I get asked a lot about how the volatile keyword interacts with arrays, so it is probably worth a blog post on the subject. Those of you who have read my posts on volatile (Volatile Fields and Synchronization, Volatile Does Not Mean Atomic and, most importantly, What Volatile Means in Java) will have a pretty good idea of what volatile means, but it is probably worth it to provide a reminder.
Basically, if you write to a volatile field, and then you have a later read that sees that write, then the actions that happened before that write are guaranteed to be ordered before and visible to the actions that happen after the read. In practice, what this means is that the compiler and the processor can't do any sneaky reordering to move actions that come before the write to after it, or actions that come after the write to before it. See my post on What Volatile Means in Java for more detail. With that out of the way, let's go through some examples of what you can do with volatile arrays:
State: You're Doing It Wrong - Alternative Concurrency Para. Transaction strategies: The High Concurrency strategy. A Beautiful Race Condition. Race-free Multithreading: Ownership. Parallel Programming in Common Lisp. Race-free Multithreading. There’s a third “hard thing” about concurrency. A Curious Course on Coroutines and Concurrency. Types for Concurrency. Use Threads Correctly = Isolation + Asynchronous Messages. LBQ + GC = Slow. Wp_otc.pdf (application/pdf Object) Benign data races in Java. Functional building blocks as concurrency patterns. Two-Phase Commit at Paper Trail. Concurrency is a Myth in Ruby. Toward Better Concurrency. Threadless Concurrency with Actors for Elite Java Programmers.
Coroutines in C Redux. Coroutines in C. Java Concurrency - A Tutorial. Double Checked Locking. Stick a fork in it, Part 1. Multitasking for Common LISP.