Re: [Harbour] MT extensions

2008-11-01 Thread Szakáts Viktor
SYNC[RONIZED] is much better than CRITICAL. Still, the only problem with it that it used a different term than our other Harbour functions targeting the same feature (hb_mutex*()). Brgds, Viktor On 2008.10.31., at 17:12, Mindaugas Kavaliauskas wrote: Java uses the keyword mutexed which IMO

Re: [Harbour] MT extensions

2008-10-31 Thread Saulius Zrelskis
Hi Przemek, 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

Re: [Harbour] MT extensions

2008-10-31 Thread Szakáts Viktor
We shouldn't be in sync with C# terminology at all. It's a completely different product. If we have MUTEX (== lock in C#) and SEMAPHORE in Harbour, this is IMO fine. These are pretty well known names. lock is IMO very generic, can mean many things. I we are to support mutex/semaphore with

Re: [Harbour] MT extensions

2008-10-31 Thread Przemyslaw Czerpak
On Fri, 31 Oct 2008, Saulius Zrelskis wrote: Hi Saulius, 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

Re: [Harbour] MT extensions

2008-10-31 Thread Alex Strickland
Przemyslaw Czerpak wrote: CRITICAL FUNCTION | PROCEDURE probably is quite easy to understand term in current days. Opinions? I like it, it immediately made me think of critical sections, and when I looked them up on Wikipedia it said: In concurrent programming a critical section is a

Re: [Harbour] MT extensions

2008-10-31 Thread Szakáts Viktor
Then we should probably also have hb_criticalsection*() functions instead of hb_mutex*() to not use two different terminologies in different parts of Harbour. Critical is a programming terminology from a lower level perspective (I wouldn't want to elaborate on the possible roots of the term, but

Re: [Harbour] MT extensions

2008-10-31 Thread Mindaugas Kavaliauskas
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

Re: [Harbour] MT extensions

2008-10-31 Thread Przemyslaw Czerpak
On Fri, 31 Oct 2008, Szak�ts Viktor wrote: Hi Viktor, 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

Re: [Harbour] MT extensions

2008-10-31 Thread Szakáts Viktor
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

Re: [Harbour] MT extensions

2008-10-31 Thread Horodyski Marek (PZUZ)
Pls. don't make any changes in this statments till mondey. I mus prepare example. Regards, Marek Horodyski ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] MT extensions

2008-10-31 Thread Mindaugas Kavaliauskas
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? Hi, I do not know Java well. I've wrote a single applet in my life. It has method: public synchronized void

Re: [Harbour] MT extensions

2008-10-31 Thread Przemyslaw Czerpak
On Fri, 31 Oct 2008, Mindaugas Kavaliauskas wrote: Hi Mindaugas, one more proposition: SYNC[HRONIZED] I though about it at the beginning but there is one problem. We already have SYNC METHODS for xbase++ compatibility. This mechanism has one side effect which is xbase++ compatible: before

Re: [Harbour] MT extensions

2008-10-30 Thread Szakáts Viktor
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

Re: [Harbour] MT extensions

2008-10-30 Thread Przemyslaw Czerpak
On Thu, 30 Oct 2008, Szak�ts Viktor wrote: Hi Viktor, 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. It's much older term

Re: [Harbour] MT extensions

2008-10-30 Thread Szakáts Viktor
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

[Harbour] MT extensions

2008-10-29 Thread Przemyslaw Czerpak
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()

Re: [Harbour] MT extensions

2008-10-29 Thread Pritpal Bedi
Hello Przemek Przemyslaw Czerpak-2 wrote: I will want to introduce two extensions for MT mode. 1. allow to use hb_mutexCreate() as static variable initialization. If we unblock using hb_mutexCreate() as static variable initializer (now we can use only fully optimized functions:

Re: [Harbour] MT extensions

2008-10-29 Thread Przemyslaw Czerpak
On Wed, 29 Oct 2008, Pritpal Bedi wrote: Hi Pritpal, CRITICAL PROC p() is the easiest way. It depends on context. There are situations where it cannot be used as mutex replacement - you will end with mutex simulation using critical function and conditional variable. Can it be implemented in