On Mon, 24 Jan 2000, Jiri Baum wrote:

<clip>
> Actually, all the words are used for that concept
>
> sleep(3) and wait(2) are both system calls [*].
>
> However, the words "sleep" and "wait" are also used generically in the
> sense of waiting for some service, while other times the words "blocked" or
> "suspended" are used. Presumably "pause" may be used in the same sense too,
> because of pause(2), but I don't recall seeing it anywhere.
>
> See eg the manpages for semop(2), open(2) or wait(2).

I stand corrected and really must consider my responses more and try to maintain accurracy (Thats the second time I've been caught on unconsidered responses ).

Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

On Sat, Jan 22, 2000 at 04:01:14PM +0000, Dave West wrote:
> On Sun, 23 Jan 2000, Jiri Baum wrote:

> > That's why you don't do those kinds of syscalls in a time-critical
> > process, no? (Only blocking calls should yield the processor, and most
> > of those have an option for failing with EAGAIN instead.)

> Not true. Blocking calls *must* yield the processor.

I never said they don't - I said that *only they* should, though. No other kind of call should yield the processor.

That said, there are calls that only block sometimes. When the operation can be completed immediately, there's no reason to block. For example the wait operation on a semaphore (ie, a semop(2) call with sem_op<0).

> For non blocking it can depend on all sorts of stuff mainly the timer
> tick.

Even the standard kernel allows you to switch off pre-emptive multitasking for a particular process. The process will then run whenever it can, as long as it can (and quite possibly starve everything else but the kernel).

> Any way if you know that you must complete within 1 msec and it takes 10 > usec to run you code wich calls say 5 syscalls but you also know that > each one will return within 5 usec because no ther process takes longer > than that to run before blocking then the standard kernel will allow you to complete well before deadline. <

A process being pre-empted has nothing to do with syscalls. The kernel yanks away the CPU whenever it feels like it.

There are some syscalls that block, but that's not really pre-empting, because you expect a file-read (say) to take a while or a semaphore wait to
sleep on the semaphore.


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi,

If I interpret Phil Covington's posts on RTL et al correctly:
- standard Linux allocates 10 msec slices of CPU time
- no user process can expect to get consecutive slices
- the interval between any one process' time slices could easily vary from 10 - 100 msec

Now, when we talk of PLC program scan times, are we talking about time from start to finish or time from start to start? I think that the scan
times reported by A-B PLC's are start to finish. This is also what the msec/K rating implies.

It is a standard selling point of soft PLC's that they execute program much faster than the 'real' ones. This is undoubtedly true, however the most significant time element is updating the I/O. For example, A-B RIO takes up to 15 msec per chassis and longer when block transfers are occurring.

Getting back to the RTL issue - I fully expect that we should be able to achieve program scan times (start to finish) equivalent to several
K/msec without special OS extensions. The issue of how fast the start to start time is, or needs to be, hinges on what you can achieve with the
I/O.

If a program executes in, say, 2 msec but is not repeated for a further 50 msec, does it pass or fail muster?

Gerry

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

On Mon, 24 Jan 2000, Jiri Baum wrote:

> On Sat, Jan 22, 2000 at 04:01:14PM +0000, Dave West wrote:
> > BTW can you name one blocking call that return EAGAIN and under which circumstances.
>
> open(2), read(2), write(2), maybe other related - when the O_NONBLOCK or
> O_NDELAY option was given to open(2) (not sure if open(2) itself can return
> EAGAIN, but it certainly won't block)
>
> semop(2) - when given the IPC_NOWAIT option and the operation would
> normally cause sleeping on the semaphore
>
> msgsnd(2) - given IPC_NOWAIT and a full queue
>
> msgrcv(2) - given IPC_NOWAIT and no message in the queue, but it will fail
> with ENOMSG rather than EAGAIN
>
> Probably others, too. See section 2 of the manual. Basically, the
> O_NONBLOCK/O_NDELAY/IPC_NOWAIT options turn blocking syscalls into
> non-blocking ones.

And thus my point. When it is given the non blocking option it is a non blocking call.
A blocking call does not return EAGAIN. yes?


Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

On Mon, 24 Jan 2000, Jiri Baum wrote:

> On Sat, Jan 22, 2000 at 04:01:14PM +0000, Dave West wrote:
> > On Sun, 23 Jan 2000, Jiri Baum wrote:
>
> > > That's why you don't do those kinds of syscalls in a time-critical
> > > process, no? (Only blocking calls should yield the processor, and most
> > > of those have an option for failing with EAGAIN instead.)
>
> > Not true. Blocking calls *must* yield the processor.
>
> I never said they don't - I said that *only they* should, though. No other
> kind of call should yield the processor.
>
> That said, there are calls that only block sometimes. When the operation
> can be completed immediately, there's no reasong to block. For example the
> wait operation on a semaphore (ie, a semop(2) call with sem_op<0).
>
> > For non blocking it can depend on all sorts of stuff mainly the timer tick.
>
> Even the standard kernel allows you to switch off pre-emptive multitasking
> for a particular process. The process will then run whenever it can, as
> long as it can (and quite possibly starve everything else but the kernel).

I wasn't aware of this capability. Given that we can do this and we have several co-operating tasks that use semaphores to share a common data area and all of the tasks will spen most of there time waiting for I/O or the semaphores then do we need to worry about RT in the conext of scan time?

> > Any way if you know that you must complete within 1 msec and it takes 10
> > usec to run you code wich calls say 5 syscalls but you also know that
> > each one will return within 5 usec because no ther process takes longer
> > than that to run before blocking then the standard kernel will allow you
> > to complete well before deadline.
>
> A process being pre-empted has nothing to do with syscalls. The kernel
> yanks away the CPU whenever it feels like it.

Does it? I always thought that the kernel only scheduled on a return from syscall. I believe the relevant code is writen in asm and has a label
ret_from_syscall:
For more clarity I thought the pre-emption worked as:
tick, tick, tick, oh time to pre-empt set a flag "resched_needed". Wait for a syscall of any type. At end of syscall check "resched_needed", if
set call scheduler and re-schedule.

> There are some syscalls that block, but that's not really pre-empting,
> because you expect a file-read (say) to take a while or a semaphore wait to sleep on the semaphore. <

I understand this fully. It's the timing of when pre-emption occurrs that I am questioning.


Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

On Tue, Jan 25, 2000 at 10:31:08AM +0000, Dave West wrote:
> On Mon, 24 Jan 2000, Jiri Baum wrote:
...
> > Probably others, too. See section 2 of the manual. Basically, the
> > O_NONBLOCK/O_NDELAY/IPC_NOWAIT options turn blocking syscalls into
> > non-blocking ones.

> And thus my point. When it is given the non blocking option it is a non
> blocking call. A blocking call does not return EAGAIN. yes?

No, not if you put it that way.

Strictly speaking, these options turn normally-blocking calls into non-blocking calls.

But I think my original phrasing was close enough as makes no difference.


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

On Tue, 25 Jan 2000, Jiri Baum wrote:

> On Tue, Jan 25, 2000 at 10:31:08AM +0000, Dave West wrote:
> > On Mon, 24 Jan 2000, Jiri Baum wrote:
> ...
> > > Probably others, too. See section 2 of the manual. Basically, the
> > > O_NONBLOCK/O_NDELAY/IPC_NOWAIT options turn blocking syscalls into
> > > non-blocking ones.
>
> > And thus my point. When it is given the non blocking option it is a non
> > blocking call. A blocking call does not return EAGAIN. yes?
>
> No, not if you put it that way.
>
> Strictly speaking, these options turn normally-blocking calls into non-blocking calls.
>
> But I think my original phrasing was close enough as makes no difference.

Yes, I'm just a pedant at heart

I really must reduce my pedanticness as I seem to be doing a lot of typing and therefore wasting some bandwidth.


Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

On Tue, Jan 25, 2000 at 11:48:09AM +0000, Dave West wrote:
> On Tue, 25 Jan 2000, Jiri Baum wrote:
...
> > But I think my original phrasing was close enough as makes no difference.

> Yes, I'm just a pedant at heart

Don't worry, I do more than my share of pedantry, too...

> I really must reduce my pedanticness as I seem to be doing a lot of
> typing and therefore wasting some bandwidth.


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Dave West:
> > > For non blocking it can depend on all sorts of stuff mainly the timer
> > > tick.

Jiri Baum:
> > Even the standard kernel allows you to switch off pre-emptive
> > multitasking for a particular process. The process will then run
> > whenever it can, as long as it can (and quite possibly starve
> > everything else but the kernel).

Dave West:
> I wasn't aware of this capability.

See the manpage for sched_setscheduler(2).

> Given that we can do this and we have several co-operating tasks that use
> semaphores to share a common data area and all of the tasks will spen
> most of there time waiting for I/O or the semaphores then do we need to
> worry about RT in the conext of scan time?

Perhaps not. We'll probably see once it's written.

But even if we do worry about RT, some of the simpler options of KURT are really just this facility with some minor improvements.

> > A process being pre-empted has nothing to do with syscalls. The kernel
> > yanks away the CPU whenever it feels like it.

> Does it? I always thought that the kernel only scheduled on a return from syscall. <

The very definition of "preemptive multitasking" means that the kernel yanks away the CPU whenever it wants to.

Otherwise any calculation-intensive application would hog the CPU.


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Jiri Baum:
> > However, the words "sleep" and "wait" are also used generically in the
> > sense of waiting for some service, while other times the words "blocked" or
> > "suspended" are used. Presumably "pause" may be used in the same sense too,
> > because of pause(2), but I don't recall seeing it anywhere.

> > See eg the manpages for semop(2), open(2) or wait(2).

Dave West:
> I stand corrected and really must consider my responses more and try to
> maintain accurracy (Thats the second time I've been caught on unconsidered
> responses ).

I think in this case the blame lies with the terminology rather than with you. Using five different words for the same concept is pretty bad.

But I don't think we can argue with tradition.

(And, btw, I think I have seen the verb "pause" - just once, in DEC Wars.)

Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc