Multithreaded notes

Some material I captured in my Google Notebook having to do with multithreaded programming:

The Little Book of Semaphores is a free (in both senses of the word) textbook that introduces the principles of synchronization for concurrent programming.

The basic functionality supported by semaphores has a certain amount of variability. The Little Book of Semaphores presents a view where only the single increment and decrement can be requested, and blocking always occurs when the resource is not available.

One particular thing that I’ve run into is that the underlying resource might be “irretrievably destroyed”; e.g. a network connection, where a list of packets is controlled by a semaphore, gets permanently closed by an error condition or network operation. Presumably, consumers of packets would wish to be awakened, but would not be able to access the resource the semaphore usually controls, and would have to notice (or be notified through an “abnormal” signalling of the semaphore) that the resource is *not* available, semaphore signal notwithstanding.But at least they are no longer blocking forever.

There are multiple ways this might be achieved

“Signal ‘enough’ to clear out any blocking consumers”

  • consumers must be programmed to check an error signal before assuming the resource became available
  • must avoid too many other consumers coming in (consumers have to check before and after blocking?)
  • arbitrary choice of “maximum”, or access to current count of semaphore (and signalling “go to zero” atomically)

“Signal all currently blocking consumers”

  • consumers must be programmed to check an error signal before assuming the resource became available
  • must avoid other consumers coming in (consumers have to check before and after blocking?)
  • i.e., notion of “currently blocking consumers” must be controlled to keep this operation atomic

“Abort”

  • wraps above functionality without explicit consumer checks; except in the sense of checking a return value for the block routine; high-level languages might trigger an exception automatically
  • could be automatically triggered by a “destroy” operation on the semaphore
  • optionally, producer could leave behind a “explanation”

“Consumers choose to timeout”

  • requires arbitrary choice of timeout
  • consumer must check for timeout vs. successful acquisition
  • producer could also leave behind “explanation”

Some of this came about through David Rager’s response to my question on the OpenMCL-devel list.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: