Hi Przemek,
It's much older term then whole MS history :-)
There is also different name for such functions:
MONITOR but who knows it in current days?
How many people have heard sth about ADA or LINDA?
I'm afraid not too much and it's really sad :-(
People like to hear about *new* XYZ "technology"
and do not even know that someone reinvent a wheel
and this "new technology" was documented over 30
years ago.
CRITICAL FUNCTION | PROCEDURE probably is quite easy
to understand term in current days. If you do not like
it then instead of creating sth new like MUTEX FUNCTION |
PROCEDURE I'd prefer to use MONITOR FUNCTION | PROCEDURE
but I do not know how it will look for native English
speakers when FUNCTION or PROCEDURE will be added to
MONITOR word.
Opinions?
Maybe I'm misunderstanding the purpose. To me proposed
"CRITICAL" looks like a way to avoid getting the execution
to the same code section twice. For example I would use it
for a very simple purpose (I already use similar technique
there currently), to avoid starting my small calculator
applet twice in my app (reason unimportant). Now, the
calculator code itself is far from being "CRITICAL" in any
sense, yet I'd like to avoid reentering the code.
Again maybe I misunderstand something, but the fact
that a given code section is desired to be protected
with MUTEXes, doesn't automatically mean that this
code section is "CRITICAL" in the meaning of the word
"critical".
MONITOR is even more cryptic to me :)
The other aspect to consider is that we would this way
introduce new word (CRITICAL/MONITOR) for an already named
entity in Harbour (MUTEXED/HB_MUTEXED). This is a little
bit confusing, even if there are more precise historical
terminologies for this specific feature. Ppl (like me)
will have a difficulty realizing that a CRITICAL FUNC
is in fact a FUNC automatically protected by a MUTEX.
[ I've never had the chance to program aircrafts, so ADA
is unfortunately not very close to me, but I didn't give
up yet to take a closer look into it once. LINDA was
a TV series in HU TV long ago, the main character was
a young lady able to yell in high frequencies while
doing something like karate. Other than this, it was
quite good by those days' standards :) BTW, the LINDA
you're talking about has an interesting naming history :)
Admittedly I haven't heard of it till today though. ]
As for making hb_mutexCreate() a special function
exception allowed in STATIC initialization looks
a bit strange as a syntax, so maybe we could
rather consider using syntax like MUTEX STATIC s_mtx.
Which means the variable is a MUTEX per definition.
Or maybe just MUTEX s_mtx, but that may make things
more complicated to implement.
I do not find it more stranger then current:
static s1 := CTOD( "" )
static s2 := HB_STOD( "20081030" )
static s3 := UPPER( "abc" )
static s4 := EMPTY( 1 )
static s5 := IIF( AT( "c", "abcdef" ) != 0, 10, 20 )
[...]
These are side effects of compile time optimization,
and at the end of the day all variables are getting
assigned _constant_ values at compile time.
In Harbour just like in Clipper all functions optimized at
compile time to simple expression can be used to initialize
static variables. We can simply define that hb_mutexCreate()
is yet another fully optimized functions (internally it will
not be but this is not visible for Harbour user).
This was the reason why I felt it "strange". Here, the
STATIC var gets a value at runtime, yet the syntax implies
otherwise.
Users may wonder how is this possible for this function,
but not for others.
Introducing new construction like MUTEX STATIC s_mtx looks
nice but it will not be able to prevent users against overwriting
s_mtx in the code. I can block assign and passing s_mtx by references
but in such case it will mean that we introduce real new exception
not yet another "fully optimized" function and it will force deeper
compiler modifications.
I think that's a lesser problem, and also a problem with
your proposed syntax. With 'MUTEX STATIC s_mtx', the only
worrying aspect is there is no visible assignment, yet in
that sense it still resembles to a MEMVAR or FIELD declaration,
which are well known. Maybe MUTEX or HB_MUTEX is enough
without STATIC, since it cannot be anything else anyway.
Given so far available information I maintain my suggestions: :)
MUTEX <mtx_whatever>
MUTEXED FUNC | PROC
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
