[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OT: Politics of Java



On Sun, Dec 15, 2002 at 09:09:48AM -0800, Craig Dickson wrote:
> Eric G. Miller wrote:
> 
> > On Sat, Dec 14, 2002 at 08:46:43PM -0800, Craig Dickson wrote:
> > 
> > > Yes, but the question is, how usable is it in practice? 
> > [snip]
> > 
> > People use "tasks" in Ada on a regular basis.  So, it must be usable,
> > neigh?
> 
> By the same reasoning, concurrency support in C and C++ must be really
> great, because there are lots of multithreaded programs written in those
> languages. I've written many myself. Yet, in fact, there is no
> concurrency support at all in those languages.

Yes, it isn't much of an argument for.  As I inidicated originally, I
just was pointing out the capability but don't have enough experience
to argue the merits of one approach vs. another.  I've looked at what
is involved for C to do threading vs. Ada, and the Ada approach is
at least superficially much cleaner (as it is part of the language
design).  Also, the tasking mechanism is supposed to be available
even when the underlying OS doesn't have direct support (say DOS).
It is up to the compiler/run-time to handle the platform details...

> > 3
> >   * a call on a protected subprogram of a protected object, providing
> >     exclusive read-write access, or concurrent read-only access to
> >     shared data;
> 
> What makes a subprogram "protected"? Is this a keyword or something that
> the programmer has to put in the right place, like Java's
> "synchronized"?

I don't know Java, but "protected" is a keyword.  But, you don't just
stick it anywhere anymore than you would stick "class" wherever.

> > 8
> >     In addition, tasks can communicate indirectly by reading and
> >     updating (unprotected) shared variables, presuming the access is
> >     properly synchronized through some other kind of task interaction.
> 
> This sounds like "thread synchronization is the programmer's problem",
> at least for the case of unprotected variables.

AFAIK, yes.

> This all sounds considerably more portable than C threading (which is
> dependent either on calling OS services directly, or using a third-party
> library that may not be available on all platforms, or may have
> licensing issues), but not necessarily all that much better. The crucial
> point, to me, is that for at least the most common kinds of thread
> communication and data sharing, it should not be necessary for the
> programmer to remember to do anything extra (like mark functions or
> variables with a special thread-safety keyword). Erlang meets this
> requirement in spades; I don't know of another language that does.

Ada is really fairly low-level like C or C++.  I have not investigated
Eiffel much, but people seem to ooze affection when talking about it.
So, I'd be interested to see if/how it approaches the matter.  Anyway,
different languages meet different needs and none will probably ever be
a magic bullet.

-- 
"...the plural of anecdote is [not?] data."  - attrib. to George Stigler



Reply to: