Hi Przemek,
This looks good to me, but the name CRITICAL
to me doesn't really seem to imply the underlying
functionality, it also sounds a bit Windows-like,
so if possible, I'd suggest some other name.
Like MUTEX FUNC|PROC.
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.
Just some thoughts.
Brgds,
Viktor
On 2008.10.29., at 17:37, Przemyslaw Czerpak wrote:
Hi All,
I will want to introduce two extensions for MT mode.
1. allow to use hb_mutexCreate() as static variable initialization.
It should help in writing MT code which have to use mutexes from
program startup and there is a problem with initializing them.
I added hb_threadOnce() function which resolves the problem but
it always has some speed overhead and make the code more complicated
then it can be. F.e. now we can write MT safe code which needs
static local mutex in the following way:
proc p()
static s_mtx, s_once
[...]
hb_threadOnce( @s_once, {|| s_mtx := hb_mutexCreate() } )
hb_mutexLock()
[...]
hb_mutexUnlock()
[...]
return
If we unblock using hb_mutexCreate() as static variable initializer
(now we can use only fully optimized functions: static s :=
HB_BITOR(1,2))
then the same code can be reduced to:
proc p()
static s_mtx := hb_mutexCreate()
[...]
hb_mutexLock()
[...]
hb_mutexUnlock()
[...]
return
It should help users in many places. Now it's possible to use as
workaround file wide static variables and INIT procedures but it
does not resolve the problem when some functions can be activated
from other INIT code and makes the final code more complicated then
necessary.
For final user the above modification will mean that
hb_mutexCreate()
behaves like other fully optimized functions and can be used for
static variable initialization.
2. CRITICAL FUNCTION|PROCEDURE
I recently wrote about them message to Marek Horodyski and I said
that
they do not give any new functionality in comparison to explicit
use of
mutexes but I recently rethink the problem and I'm finding two
features:
- user cannot forgot about unlocking the mutex because it will be
unlocked
by HVM automatically
- HVM will unlock them in all cases also when thread generate
exception
like QUIT or BREAK so it's not necessary to use BEGIN SEQUENCE /
ALWAYS
statment as protection, f.e. with above modification I can write
code
like:
proc p()
static s_mtx := hb_mutexCreate()
hb_mutexLock()
[...do sth...]
hb_mutexUnlock()
return
but if [...do sth...] can generate exception, f.e. RT error then
I should add protection code which will always unlock the mutex:
proc p()
static s_mtx := hb_mutexCreate()
hb_mutexLock()
begin sequence
[...do sth...]
always
hb_mutexUnlock()
endsequence
return
With CRITICAL functions/procedures to reach the same effect it
will
be enough to make:
critical proc p()
[...do sth...]
return
Both modifications are similar but they are not fully replaceable so
I want to introduce both.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
