Quote from: HimyKabibble on February 07, 2010, 02:21:34 PM

Could well be you know something I don't, but neither Art nor Brian has ever indicated to me that IsMoving() is a *guarantee* of a UI update.  In fact, on occasion, Brian has suggested using a delay.  Certainly, if the machine is idle, a delay of 2X the update rate *should* guarantee an update has occurred, as UI updates are regular, timed events, unless the machine is too busy running a program.  But, as I said, v4 will be FAR better in this respect.  It is a little ridiculous for user to have to worry about this kind of stuff.

Ray

I wouldn't presume to think such a thing and I'd absolutely agree with what you say Art & Brian have said and I don't think I've said anything to the contrary. In an ideal world of course it would be nice if the semaphore was accompanied by the called thread's success or error status but we can't have everything.

I think you'd agree that mult-threading is not unique to Mach and I've based what I've said on the assumption that Mach implements it in much the same way as any other multi-threading application - if not then I'd be intrigued to know how and why.

Certainly if a called thread is expected to complete after a particular time, then a wait by the calling thread for some period longer than that *should* give expected results. But when a semaphore is available, I would suggest that it is better practice to use it.

The only reason I can think of where a wait might be preferable, would be if there were some concern over the reliability of the code implementing the semaphore. Not that I'm suggesting this is the case with Mach of course.

Cheers

Ian

Ian,

I agree 100% about the use of semaphores.  But, one thing I've learned about Mach3 is that many features are not implemented anywhere near the way they "should" be.  Many are basically "hacks" that sorta-kinda work most of the time.  I've come across some real doozies where I can only scratch my head in disbelief.  This is why v4 is taking so long - Brian is working very hard to get that kind of stuff out, and the deeper he digs, the more he finds that just needs to be ripped out and re-done from the ground up.  He's already completely re-architected many whole major sections of Mach3.  v4 will be MUCH better in all respects.

Regards,
Ray L.

Ray

Understood. I'll add myself to the list of those keenly awaiting V4.

Cheers

Ian

Is this  better?  From the Mach 3 wiki:


A frequent requirement is to have to wait for Mach3 when doing several commands, to keep them executing in order. The:

While IsMoving
Wend

Loop is the typical way of doing this.

ex:

code "G0X100"
While IsMoving()
Wend

However, this causes the system to make millions of calls to the subsystem to determine if Mach3 is finished. The CPU load rises terribly. A solution is to wait for 100ms or so each time you check unless you need a very tight response time. The solution is to use a syntax as follows..

Declare Sub Sleep Lib "Kernel32" (ByVal dwMilliseconds As Long)
.
.
.
Code "G0X100"
While ismoving()
Sleep 100
Wend

I suppose its somewhat moot, since this will go away in V4.

Is this  better?  From the Mach 3 wiki:


A frequent requirement is to have to wait for Mach3 when doing several commands, to keep them executing in order. The:

While IsMoving
Wend

Loop is the typical way of doing this.

ex:

code "G0X100"
While IsMoving()
Wend

However, this causes the system to make millions of calls to the subsystem to determine if Mach3 is finished. The CPU load rises terribly. A solution is to wait for 100ms or so each time you check unless you need a very tight response time. The solution is to use a syntax as follows..

Declare Sub Sleep Lib "Kernel32" (ByVal dwMilliseconds As Long)
.
.
.
Code "G0X100"
While ismoving()
Sleep 100
Wend

I suppose its somewhat moot, since this will go away in V4.

You are correct - you should *never* use:

While IsMoving()
Wend

Rather *always*

While IsMoving()
    Sleep(10)
Wend

The length of the Sleep is not important, but having a Sleep in there is important, to avoid wasting many, many CPU cycles.

Regards,
Ray L.

but I think I'm right in saying you don't need the "Declare Sub Sleep Lib "Kernel32" (ByVal dwMilliseconds As Long)" as it's "implicitly" declared for you already.

Cheers

Ian

Sure...  I think the wiki writer just meant to show the syntax of Declare Sub Sleep Lib "Kernel32" (ByVal dwMilliseconds As Long)  there, and did not intend for that to be part of the code snippet in the example.

That was the way I took it, at least.