[concurrency-interest] wikipedia article

David Holmes dcholmes at optusnet.com.au
Wed Jun 28 20:00:45 EDT 2006

The reference re Microsoft is completely incorrect. There was a very early
Java Threads whitepaper that defined a strict priority-based scheduling
model. That model was not implementable on Solaris or Windows at the time,
without involving the real-time scheduling classes of the OS. The spec was
subsequently relaxed.

Second any reference to "protecting code" versus "protecting data" is very
misleading and confusing. You protect data by controlling the code that
accesses that data. The level of abstraction at which you do this then lends
some people to characterise as "protecting data" or "protecting code". An
abstraction involving shared objects that can't be accessed in anything but
a thread-safe manner would be classified as "data protection". Java doesn't
provide that directly but allows you build this by applying "code
protection" in the right way.

David Holmes
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Dhanji R.
  Sent: Thursday, 29 June 2006 9:36 AM
  To: concurrency-interest at cs.oswego.edu
  Subject: [concurrency-interest] wikipedia article

  I came across this article on wikipedia:

  Although I am generally wary of anything wikipedia says, it's often ok for
minor technical definitions and such. But I was bothered when I read the
following points:

    It was not immediately suitable for Real time systems for two reasons:

      a.. The threading behavior was largely unspecified. This, reputedly,
was a concession to Microsoft to allow for the weak threading models
underlying the Microsoft Windows operating system at the time.
      a.. Still, there is only one synchronization primitive available for
Lock (software engineering), the Monitor (synchronization) pattern, meaning
that only code sections can be guarded, not data.

  Obviously the article is quite out of date, but was it true that the poor
threading model in early java was a concession to Microsoft?

  Also, data can be guarded directly with j.u.c.atomic--if I'm not mistaken,
obviating the second point?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060629/553b58b6/attachment.html 

More information about the Concurrency-interest mailing list