casey@asi.com (Casey Bahr) (03/29/91)
Are there any VxWorks scheduling gurus out there? Hello? I have an application that normally runs about 5 concurrent tasks and over the course of develpoment I've had some trouble in getting them scheduled equally by the OS (running on an mvme147). Before 5.0 my solution was to hand-tune the priorities to get everyone going, which seemed to work fine, once I found the proper relative priorities. Now with 5.0 most of the tasks seem to get scheduled fine, except one, which seems to get locked out (waiting at a socket accept() call). So, I tried using the round-robin scheduling feature by calling kernelTimeSlice() with values from 1 to 10 (seemed reasonable) and combining that with leaving my task priorities as they were without round-robin, and by changing the priorities to be equal (as implied by the VxWorks release notes). Using round-robin scheduling seemed to make matters worse, by seemingly shutting out > 1 task. Worse yet, after using round-robin scheduling interrupts from the console terminal keyboard seemed to be all messed up, not taking strokes, doubling or tripling them up, etc. Had to shut down the mvme147 to correct this. Not sure this latter symptom is relevant, but it was entertaining. Any experiences relevant to my situation and possible solutions much appreciated. Thanks in advance :} Casey Bahr casey@asi.com | ogicse!adaptive!casey | uunet!adaptive!casey Adaptive Solutions, Inc., 1400 NW Compton Dr. Suite 340, Beaverton, OR 97006 VOICE: (503) 690.1236 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ FAX: (503) 690.1249
hwajin@sgi.com (Hwa-jin Bae) (03/30/91)
>>>>> On 29 Mar 91 01:24:18 GMT, casey@asi.com (Casey Bahr) said:
Casey> Now with 5.0 most of the tasks seem to get scheduled fine, except
Casey> one, which seems to get locked out (waiting at a socket accept() call).
When a task is "locked out" waiting at a socket accept() call, it is
basically pending on a semaphore (pending on a semTake()), which will
not return until the semaphore you're pending on is available. This
is the proper behavior. In most cases, this is also desired behavior
since you want this task to pend until a connection is accepted. If
your application doesn't want to pend forever on a semaphore waiting
for a new connection, you should use select(), which takes a timeout
value. Upon return from select() you can check if there's anything
interesting going on on the socket. You can then choose to accept()
or do something else.
*hwajin
--
Hwa Jin Bae hwajin@{pei.com, wrs.com, igc.org, unisoft.com}
Protocol Engines, Inc.
Mountain View, CA