text: about concurrency (again)
  - From: "michele.simionato@xxxxxxxxx" <michele.simionato@xxxxxxxxx>
  - Date: Sun, 18 Nov 2007 22:32:50 -0800 (PST)
  I have been reading the recent thread about concurrency, which is
  unfortunately
  for the most part over my head, and I wanted to assess what I
  understand
  of concurrency (or I think I understand).
  In particular I wanted to make clear what do you mean for message
  passing
  and what is the name for the model I have in mind, since I actually
  lack a formal
  training on concurrency. I will make a very simple example to make
  things
  crystal clear; please forgive me if I am too pedagogical.
  Suppose I am testing a software for launching nuclear missiles (this
  is
  just to make things a bit more melodramatic;). I will have routines
  like the following (let me use Python, since I am more confortable
  with it):
  safe_mode = True
  def enable_safe_mode():
  global safe_mode
  safe_mode = True
  def disable_safe_mode():
  global safe_mode
  safe_mode = False
  def launch_nuclear_warhead():
  if safe_mode:
  print 'Just emulating the launch of a nuclear warhead'
  else:
  print 'You just launched a nuclear warhead!'
  def test_launch():
  enable_safe_mode()
  launch_nuclear_warhead()
  When I call test_launch, nothing bad happens, since I have enabled the
  safe_mode flag and I feel confident that my code has no bugs.
  Suppose now that a collegue of mine is doing tests with the safe_mode
  setting routines:
  def test_safe_mode():
  try:
  disable_safe_mode()
  finally:
  enable_safe_mode()
  Notice that my collegue is very careful to re-enable the safe mode
  after he
  tested disable_safe_mode, so he is also confident that his code has no
  bugs.
  Both routines are actually correct for non-concurrent code, but they
  are buggy in presence of concurrency. Actually if both test_launch
  and test_safe_mode run simultaneously the following scenario may
  happen,
  in a non-deterministic way:
  1. in test_launch enable_safe_mode is called;
  2. in test_safe_mode disable_safe_mode is called;
  3. in test_launch launch_nuclear_warhead is called;
  4. the warhead is fired!
  5. in test_safe_mode enable_safe_mode is called, but too late :-(
  How do we avoid firing the missile? The usual solution is to put locks
  everywhere but it is clearly too invasive. What I would do (and I
  would
  like to know how this approach is called in the literature) is to
  introduce
  a message_manager object which dispatches to the right routines and
  takes care of the locks in a centralized way. One possible
  implementation
  could be the following:
  def message_manager():
  while True:
  with threading.Lock():
  message = yield
  # "instantiate" the manager in the main thread
  manager = message_manager()
  manager.next()
  # send messages like manager.send(test_launch)
  Now different threads can send to the manager a message (the message
  is the routine the manager should call) and be assured that the
  messages will be processed sequentially. Basically the manager is
  converting back the critical parts of the application to single-
  threaded
  mode. The same discussion clearly applies to independent process,
  where
  the safe_mode flag could be stored in a file or in a database and
  the lock could be a file lock or a transactional lock.
  How would you improve over this solution and what would you
  recommend?
  Concrete examples are welcome!
  Michele Simionato
  .
  - Follow-Ups:
  - Re: about concurrency (again)
  - From: David B. Benson
  - Prev by Date: Re: A really basic question about category theory
  - Next by Date: Re: Concurency in the functional world
  - Previous by thread: A really basic question about category theory
  - Next by thread: Re: about concurrency (again)
  - Index(es):