Meyer, OO and concurrency

[David Hopwood]

todd wrote:
> David Hopwood wrote:
> 
>> Nothing, *for this example*. But if the semaphore (or any other kind of
>> concurrency construct) were provided by a language, then the language 
>> would have a lot to do with it.
> 
> If it were provided by the language how would a latency guarantee be 
> possible given the language doesn't control the CPU?

By implementing the semaphore (in this example) entirely at user level.

In general, problems in supporting real-time guarantees (latency, fairness,
etc.) can be due to the OS definition, OS implementation, language definition,
or language implementation. But some of these problems can be worked around,
or the problematic features can be avoided. If the language works around or
avoids problems with the OS, then a programmer does not need to be concerned
with those problems at all.

For example, suppose that an OS provides adequate support for real-time
scheduling and for pinning memory pages (and therefore is able to run
selected user-level code with low latency), but all of its synchronization
abstractions are broken in respect of latency guarantees.

Never mind; it is possible to implement synchronization at user level, by
making use of atomic operations and/or memory barriers supported by the
processor architecture, bypassing the OS. Or, the language design and
implementation may make it unnecessary to use explicit synchronization at
all.

Of course, if a language implementation is running on an OS that is
hopelessly broken in respect of real-time issues, and does not allow
running *any* code with low latency, then the implementation will also
be hopelessly broken in that respect. This is just as true of C++ as it
is of Erlang.

-- 
David Hopwood <david.nospam.hopwood@REDACTED>