Hi Przemek,
Then we should probably also have hb_criticalsection*()
functions instead of hb_mutex*() to not use two different
terminologies in different parts of Harbour.
I do not agree. The internal synchronization mechanism used
on low level is our own choice which should be tuned to
best .prg code performance and protection. We can internally
use different synchronization mechanism for functions and
.prg mutexes on some platforms. It's not user problem to guess
which ones.
I was solely talking about .prg level. We already have
hb_mutex*() (which is perfect), now we want _mutex_
protected functions, which we want to give another name,
based on the facts that such code part may be "critical"
by one of the original meanings of this term, while I think
it should also use mutex for simplicity and clarity.
F.e this way I could just 'grep' for MUTEX to find all
of my code, which is for some reason not fully reentrant.
I see there are CRITICAL words in low level .c code though,
which is IMO perfectly right, and private matter to
Harbour core developers.
Critical is a programming terminology from a lower level
perspective (I wouldn't want to elaborate on the possible
roots of the term, but it looks to originate from low level
OS programming), and there, critical may indeed mean critical,
but in Harbour .prg level this looks like a way too harsh
word and seems to be somewhat disconnected from the world
of such a high level programming language. "critical section"
seems to mean a subset of the more generic term "mutex".
No wonder high level languages (C#/Java/XBase++) don't use
the "critical section" terminology.
They do. They discribe code protected by synchronization mechanism
as CRITICAL SECTION.
Exactly, but they don't use it as a syntax element.
If you read the wikipedia article to the end, it turns out
that POSIX calls "critical sections" simply "mutex", and
In POSIX documentation you can find that MUTEXes are synchronization
mechanism to guard CRITICAL SECTION of code, f.e. copy and past from
simple search:
The prioceiling attribute defines the priority ceiling of
initialized
mutexes, which is the minimum priority level at which the
critical sec-
tion guarded by the mutex is executed. In order to avoid
priority
the only cited example where it's called "critical sections"
is in Windows itself, which is an operating system, where
such name can even have a real meaning on that low level.
Not true see above.
"critical section" may be the academic name of such protected
code parts, but only low-level Windows uses it in as an API
function name. I'm not talking about theory, but practice.
They've probably named it that way because they've used
up "mutex" for the inter-process variation. (this is in
sync with C#, but there they've named intra-process,
I do not think so. When CRITICAL_SECTION was introduced to Windows
MUTEX was not well know term but CRITICAL SECTION was. Even today
many people prefer to use SEMAPHORE instead of MUTEX.
My point is that "critical" and "critical section"
is not used in the majority, high-level programming
languages as part of any syntax. Only Windows OS seems
to use it as an API function name, and I've found
Delphi (still Windows world) using it for one its objects.
I'm not disputing the original meaning of "critical
section", but practice shows that it didn't make it
to languages for some reason. Which may or may not be
because of those concerns I'm trying to express, but
the trend seems clear.
Maybe the reason is just that "MUTEX" is unambiguous
and short, while "CRITICAL" is ambiguous and alarming,
while "CRITICAL SECTION" is less ambiguous, but long.
[ I also use SEMAPHORE, but I see no problem clearing
the ambiguity by having binary semaphores as MUTEXes,
and 'counting' semaphores as SEMAPHORES. BTW, I also
use FS-wide "userlock"s locally. This should also
be semaphores ideally. For files and databases we
also use "lock"s, which is again something like an
FS-side mutex. ]
aka 'critical sections' ones simply 'locks', probably for
similar reason I'm trying to show).
Also, "critical" by itself doesn't mean anything above, it's
always used in conjunction with "section", so the term
or CODE or INTERRUPT or EXCEPTION or HANDLER or OPERATION or
SERVICE ...
Some of them are used in very similar context to CRITICAL FUNCTION |
PROCEDURE.
I don't agree with this. Maybe HANDLER and SERVICE are
vague by themselves, but CRITICAL by itself, at least for
normal ppl not knee deep into low level programming
(think of 'simple' .prg, C#, Java programmers), means not
much I'm afraid, besides looking pretty alarming.
is "critical section". If we say "critical function/procedure",
or just "critical" as a single word, to me it looks something
completely different.
CRITICAL SECTION in informatics terms means peace of code which should
not be interrupted by other code/events.
Yes, that's the meaning I used to know it, and it's
wholly different from a piece of code which we don't
want to be executed more than one times in parallel.
That also means that even the academic meaning of
"critical section" is ambiguous.
In MT programming it was adopted as peace of code which can be entered
only by one thread. But in fact it's not common definition. This
term is also used to define peace of code which can be executed only
when all other threads or processes are stooped. It's also used to
define peace of code which cannot be interrupted by any exceptions
or OS scheduler.
Again low-level. Regular Harbour programs don't operate
in that low level world. Interrupts don't happen, exceptions
are rather RTEs, and we don't handle hardware or other
subtleties, at least usually, which probably means something
around 99% of cases.
Java uses the keyword "mutexed" which IMO tells it best
that a given object is automatically protected by a mutex.
I didn't know about it. Can you show the whole syntax?
I'm no Java expert. Just found significant number of mention
of this on the web. It may be part of an addon, or part of
it's class hierarchy. Anyhow the term "mutex" is actively used
in Java world, while the other is not.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
