Weblogs Forum - Other Programmers and Shared-Memory Concurrency

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Other Programmers and Shared-Memory Concurrency

32 replies on 3 pages. Most recent reply: Sep 28, 2007 6:09 PM by Raoul Duke

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 32 replies on 3 pages [ « | 1 2 3 | » ]

Marco Fabbri

Posts: 2
Nickname: mfabbri
Registered: Dec, 2004

Re: Other Programmers and Shared-Memory Concurrency

Posted: Sep 18, 2007 8:00 AM

Reply

Advertisement

This is not strictly Python-related, but having mentioned Agents, I want to let you know that a discussion on similar topics is ongoing in the Agents Research Community, at the Agent Oriented Computing (work in progress) site: http://projects.alice.unibo.it/course/view.php?id=3 . AOC communty is discussing the notion of Agents and Multi-Agent Systems as a paradigm for software development; rising the abstraction level adopting agents allows to better capture the essence of concurrency-related problems and having agent-like abstractions "alive" during the whole software system lifecycle will improve testability, and manageabilty.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Other Programmers and Shared-Memory Concurrency

Posted: Sep 18, 2007 8:11 AM

Reply

> There are such abstractions. They are called Fork,
> Process, Shared Memory
Once you've shared the memory you have exactly the same concurrency issues as with threads, except that synchronization primitives are probably more expensive.

If you don't share the memory then some types of parallel computation are more expensive.

Then we come to the suggestion of doing your heavy lifting in some other language (usually Fortran, C++). I hate this approach as it tends to lead to the heavy lifting code (and coders) being in a ghetto marked "here be dragons". Also duplication of effort with some facilities being (re)implemented in each language involved.

I suppose it is only a minor detail to note that the efficiency and even existence of those primitives (fork, process) is system dependent.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Other Programmers and Shared-Memory Concurrency

Posted: Sep 18, 2007 9:31 AM

Reply

> I'm really disappointed that people keep chanting the
> 'nobody can write correct concurrent code because it is
> too complicated' mantra. I guess I'm dreaming when I see
> C++ and java app servers here running complex applications
> without any problems. Even when they sometimes use
> thousands of threads to do their work.

I'm not saying "correct concurrent code," but rather "correct code using shared memory threading."

> It is funny that you mention Brian Goetz because he
> actually spells out very clearly that writing concurrent
> code (in Java) is certainly not impossible and also not
> rocket science. I'm sure you are familiar with his book.

Brian spent a lot of time and effort helping me with the concurrency chapter in TIJ4.

I've had discussions with Brian since he's written the book, and he's changed his attitude. Wait a few days, Bill is going to interview Brian and I expect the result (to be published on Artima) to be very enlightening.

And yes, in my experience, it really is rocket science. I've had numerous periods in my life where I have thought that it wasn't, and then that illusion has been dashed. Enough times that I don't believe it anymore.

You are clearly convinced that your experience is different, but I think you'll find that a true understanding of threads is not that common. More common is the illusion that one understands threads.

> For me the key to writing correct concurrent code is to
> rely on basic foundations like java.util.concurrent, by
> using proven patterns and common sense. I bet that when
> Python would have great thread support that these same
> kind of frameworks would happen in the Python eco system
> and that people would be just as confortable writing
> concurrent code in Python.

You'll see in TIJ4 that I wrote extensively about these. They are good guidelines but no guarantee of correct programs.

> Concurrent code can definitely turn into debugging hell
> with race conditions and vague problems. If you choose to
> work at that level.

Well, that's the problem. You don't get to choose, because you aren't guarded from those things, even if you think you are.

> On the other hand it can also turn into very succesfully
> putting results quickly together by using basic building
> blocks like (in case of Java) BlockingQueue,
> ExecutorService, Runnable and friends. Again, proven
> patterns.

Again, wrote about them extensively but they don't solve all your problems.

> Of course anyone can choose to use the much more low level
> threading/concurrency primitives as they please and have
> more change of shooting themselfes in the foot. But how is
> that different from ANY technology that Python currently
> exposes. Everything is potentially dangerous in the hands
> of inexperienced users.

Again, you don't get to choose. And even if you do get it right, the libraries you call often don't. They might be written by those "inexperienced users." If you've looked into some of the standard library code that's distributed with Java you may discover some code written by what would seem to be "inexperienced users," so it can happen anywhere.

I note that the majority of safe programming idioms do exactly what processes do: they cordon off the memory so that other threads can't stomp on it, and require controlled access to the resulting object.

> So I guess what I'm asking here is to let go of the Evil
> Threads idea and let people make that decision based on
> their own experience and project.

Nope, I think you've hit the nail on the head. Threading is Evil.

> I think it wil take Python to the next level and attract a
> LOT of people who are now doing very smart things in other
> languages.

I've pretty much moved to the "Save the GIL" camp because it prevents problems in the threading system we DO have. I believe parallelism should be achieved through processes.

It's great that you understand threads as well as you do, but wait until the interview with Brian comes out and it might change your thinking just a little.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Other Programmers and Shared-Memory Concurrency

Posted: Sep 18, 2007 9:39 AM

Reply

> Once you've shared the memory you have exactly the same
> concurrency issues as with threads, except that
> synchronization primitives are probably more expensive.
>
> If you don't share the memory then some types of parallel
> computation are more expensive.

Well, this sums it up, doesn't it -- for some definition of the term "expensive." I believe that with the advent of multicores, our typical way of thinking about expense in this arena is going to change. I think that ultimately, the expense of programmer time becomes the biggest issue (it always has evolved in this direction). And if you share memory, programmers will have to chase threading bugs. If you don't, programming in parallel becomes much simpler. If we throw a few extra cores at the problem in order to make programming easier and cheaper, then that's what we're going to do. Economics will be what pushes us in this direction.

> Then we come to the suggestion of doing your heavy lifting
> in some other language (usually Fortran, C++). I hate this
> approach as it tends to lead to the heavy lifting code
> (and coders) being in a ghetto marked "here be dragons".
> Also duplication of effort with some facilities being
> (re)implemented in each language involved.

Again, it's an issue of programmer economics. It usually costs more to build and maintain in multiple languages because of the mental shift required. I think it should be possible to program with multiple languages (it already is with ctypes, and if you use processes rather than threads you reduce a lot of concern about the dll behavior), but it should definitely be possible to do everything in Python because that reduces the mental load and makes us more efficient programmers -- the impetus comes from economics.

Alex Fabijanic

Posts: 71
Nickname: aleksf
Registered: Aug, 2006

Re: Other Programmers and Shared-Memory Concurrency

Posted: Sep 18, 2007 10:22 AM

Reply

> I'm really disappointed that people keep chanting the
> 'nobody can write correct concurrent code because it is
> too complicated' mantra. I guess I'm dreaming when I see
> C++ and java app servers here running complex applications
> without any problems. Even when they sometimes use
> thousands of threads to do their work.

http://www.sics.se/~joe/apachevsyaws.html

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Other Programmers and Shared-Memory Concurrency

Posted: Sep 18, 2007 12:08 PM

Reply

> Well, this sums it up, doesn't it -- for some definition
> of the term "expensive." I believe that with the advent of
> multicores, our typical way of thinking about expense in

In my area (vehicle routing, combinatorial optimization), the expectation of what it is feasible seems to grow at least as fast as the processor power available to solve it. Also the time available to produce a solution is fixed at around 15 minutes. Thus little of the growth in processor power is available to make the programmers (my) task easier.

In one of my current tasks the data shared between threads amounts to around 500MB (a figure that grows with time). So not sharing it is all but unthinkable.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Other Programmers and Shared-Memory Concurrency

Posted: Sep 18, 2007 2:27 PM

Reply

The "other programmers" motto reminded me of Blub langauges ( http://www.paulgraham.com/avg.html , and yes, I know that Paul Graham thinks my favorite languages are Blub languages). But, ...

> > I'm really disappointed that people keep chanting the
> > 'nobody can write correct concurrent code because it is
> > too complicated' mantra. ...
>
> I'm not saying "correct concurrent code," but rather
> "correct code using shared memory threading." ...
>
> And yes, in my experience, it really is rocket science.
> I've had numerous periods in my life where I have thought
> that it wasn't, and then that illusion has been dashed.
> Enough times that I don't believe it anymore. ...
>
> > Concurrent code can definitely turn into debugging hell
> > with race conditions and vague problems. If you choose
> > to work at that level.
>
> Well, that's the problem. You don't get to choose, because
> you aren't guarded from those things, even if you think
> you are.

Not too long ago, I hoped to avoid a lot of locking trouble through the type engine. Basically: (1) create only <code>unlocked_access_variables</code>, (2) define a conversion between <code>unlocked_access_variables</code> and <code>locked_access_variables</code> that does the necessary locking/unlocking, and (3) defining all functions to take <code>locked_access_variables</code>.

If I pass an unlocked variable to a function expecting a locked variable, what will happen? The variable will be converted to a locked variable (locking the underlying data), passed to the function, and (depending on the language) destroyed at the end of the function scope, thereby unlocking the data. And if the function calls another function, it will pass the *locked* copy of the data.

So what do I get up at this high altitude? First, I get to worry about the compiler optimizing away my locking or unlocking code. Second, I get to worry about deadlock unless I can guarantee that all variables are locked in the same order every time (which may mean that all function signatures have to list certain variables in certain orders). Oh, and I get to worry about people trying to control access to my objects with semaphores in some places and mutexes in others, and spinlocks in others. And I have a hunch that there are other things to worry about.

It may be time to say that shared data is just a bad way to do things. For all of it's anti-Blubness, Lisp still has limits.

Steve Anderson

Posts: 2
Nickname: thebashar
Registered: Sep, 2007

Re: Other Programmers and Shared-Memory Concurrency

Posted: Sep 18, 2007 3:07 PM

Reply

> latest hystery. My own take for process oriented
> programming in Python is the use of a generator framework
> ( very similar to Stackless Python ) and an implicit
> distribution mechanism using somewhat like the processing
> package. The question is just whether or not we want to
> program our software in this style all the way down.

My preferred tool to work with is the "nanothreads" module of Simon Wittber's FibraNet (http://pypi.python.org/pypi/FibraNet/) package. It provides a nice threadlet API using generators. You can optionally yield UNBLOCK from a nanothread and the next iteration will be scheduled in a separate thread. This works nice when you know you are about to perform some blocking IO or similar.

I also like and use the "processing" (http://www.python.org/pypi/processing) package to manage splitting some tasks off into separate processes. I like its API based on the threading module.

For me, I would like to see these two approaches integrated so that I could use the nanothreads approach but perhaps yield PROCESS to have the scheduler spawn off a processing module process.

Typically, I don't work with problems that easily fit the job-based API of the "pp" (http://www.parallelpython.com/) module, but that's not to diminsh ParallelPython in any way. It would be my first stop if I did need to do that type of thing.

Besides adding "processing" support to the nanothreads API, the only other thing I would really like to see is some read-only shared memory multi-process solution. I think the shared memory would make some types of tasks much more efficient, while limiting it to read-only would greatly simplify correctnes and implementation.

Mike Ivanov

Posts: 23
Nickname: mikeivanov
Registered: Jul, 2007

Re: Other Programmers and Shared-Memory Concurrency

Posted: Sep 18, 2007 4:51 PM

Reply

> I could use the nanothreads approach but perhaps
> yield PROCESS to have the scheduler spawn off
> a processing module process.

Sounds really interesting.

> shared memory would make some types of tasks much
> more efficient, while limiting it to read-only would
> greatly simplify correctnes and implementation.

Unfortunately, this not always will work. Consider expression b = a + a evaluated in one thread and a = a + 1 in another. Even if the first thread accesses the shared variable 'a' in the read-only mode, nothing prevents it from producing unpredictable results. Generally, that means no thread should have write access to a shared block, which is not very useful.

Steve Anderson

Posts: 2
Nickname: thebashar
Registered: Sep, 2007

Re: Other Programmers and Shared-Memory Concurrency

Posted: Sep 18, 2007 5:49 PM

Reply

> > shared memory would make some types of tasks much
> > more efficient, while limiting it to read-only would
> > greatly simplify correctnes and implementation.

> from producing unpredictable results. Generally, that
> means no thread should have write access to a shared
> block, which is not very useful.

The no write access was what I was thinking by read-only shared memory. I was thinking it would be useful where you have a large dataset to process piecemeal by independant worker threads/processes. It would be nice if you didn't have to copy each worker's presumably still large subset of the dataset. Instead, each worker could have ro access to the shared dataset and an index into it indicating its working set.

Worker results would of course need to be passed back via more conventional messaging since there are no rw shared memory areas in this hypothetical arrangement.

Adam Olsen

Posts: 11
Nickname: rhamph
Registered: Jun, 2007

Re: Other Programmers and Shared-Memory Concurrency

Posted: Sep 18, 2007 9:15 PM

Reply

> I note that the majority of safe programming idioms do
> exactly what processes do: they cordon off the memory so
> that other threads can't stomp on it, and require
> controlled access to the resulting object.

Bruce, would I be correct if I said this was the core feature you're looking for in Agents? Language-enforced barriers around mutable objects?

That's what my Monitors provide. They encapsulates all those mutable objects we know and love, but only one thread can get into a Monitor at a time. They're also limited to passing in/returning only other Monitors (or immutable objects, collectively "shareable" objects).

I still think of this as "shared-state threading", although not in the same sense C is. Perhaps we need a new term for it? I've seen "safe threads" used before (and is the working name for my fork of CPython that uses it.)

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Other Programmers and Shared-Memory Concurrency

Posted: Sep 19, 2007 12:45 AM

Reply

> in another. Even if the first thread accesses the shared
> variable 'a' in the read-only mode, nothing prevents it
> from producing unpredictable results. Generally, that
> means no thread should have write access to a shared
> block, which is not very useful.

It could be useful if the block is filled initially by one process and then when shared it is made read only in the original process as well as in others sharing the region.
One difficulty I find with interprocess shared memory is that it is usually difficult or impossible to share read only objects (i.e. something more than mere aggregates of primitive data).

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Other Programmers and Shared-Memory Concurrency

Posted: Sep 19, 2007 7:13 AM

Reply

I haven't read the whole thread from the start, but why not use the Actor model fully? i.e. every object in the language should be a different thread, and invocation of a method should be a computational job posted to the job queue of an object's thread. Condition variables should be automatically inserted when waiting for a result to be available.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

Re: Other Programmers and Shared-Memory Concurrency

Posted: Sep 19, 2007 10:44 AM

Reply

> I haven't read the whole thread from the start, but why
> not use the Actor model fully? i.e. every object in the
> language should be a different thread, and invocation of a
> method should be a computational job posted to the job
> queue of an object's thread. Condition variables should be
> automatically inserted when waiting for a result to be
> available.

Can we share data between threads in the Actors model? I think the model is not designed for that, but I'm not sure. Anyway, it looks like this would be a similar approach taken in Erlang with message-passing concurrency, but I don't think it would be a good idea to prefer one concurrency model over others for a general-purpose language.

Adam Olsen

Posts: 11
Nickname: rhamph
Registered: Jun, 2007

Re: Other Programmers and Shared-Memory Concurrency

Posted: Sep 19, 2007 11:11 AM

Reply

> > I haven't read the whole thread from the start, but why
> > not use the Actor model fully? i.e. every object in the
> > language should be a different thread, and invocation of
> a
> > method should be a computational job posted to the job
> > queue of an object's thread. Condition variables should
> be
> > automatically inserted when waiting for a result to be
> > available.
>
> Can we share data between threads in the Actors model? I
> think the model is not designed for that, but I'm not
> sure. Anyway, it looks like this would be a similar
> approach taken in Erlang with message-passing concurrency,
> but I don't think it would be a good idea to prefer one
> concurrency model over others for a general-purpose
> language.

Can you make a new class that subclasses Actor? Can you pass references to these Actor objects to other Actors? If so you can share data.

(The primary difference between Actors and Monitors is that Actors are called asynchronously by default while Monitors are called synchronously by default. I think synchronous is a more useful default.)

Flat View: This topic has 32 replies on 3 pages [ « | 1 2 3 | » ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use