With the changes I made, epicsThreadSetPriority() should -- in principle 
-- also work for non-EPICS threads,
as long as the target thread uses the same scheduling policy as pcommonAttr.

However, for sake of backwards compatibility I did not yet remove the test

     if(!pthreadInfo->isEpicsThread) {
         fprintf(stderr,"epicsThreadSetPriority called by non epics 
thread\n");
         return;
     }

(but you can find the comment:

     /* T.S.: There is in principle no problem with changing the priority of
      * a non-EPICS thread -- as long as it uses the same scheduling policy.
      * For sake of backwards compatibility I leave this test for now but
      * it could as well be removed (and the 'isEpicsThread' member as 
well).
      */
).

I.e., as a result of this discussion we could remove the above test and 
you then should be
able to set the priority of the 'main' thread.

More comments in-line below...

On 2/21/19 9:33 AM, Heinz Junkes wrote:
> Thanks Till,
>
> I'll apply that for my RTESM5 port too and test it.
> (Meanwhile I use the posix osdTthread variant also for RTEMS5).
>
> If "we" are already there, the following call has been causing problems
> for a long time.
>
> -    pthreadInfo = init_threadInfo("_main_",0,epicsThreadGetStackSize(epicsThreadStackSmall),0,0);
> +    pthreadInfo = init_threadInfo("_main_",0,0,0);
>
> So that the "ur-task" is started, during POSIX_Init. But as non Epics-task it gets the OSI-prio "0".
> Shouldn't something like IocShPrio 91 be set here?
>
> Unfortunately I can't set it in rtems_init with epicsThreadSetPriority because it is a
> non-epics-task.
>
> But in some tests we read the epicsPrio from this thread (and you get it back as 0) and then e.g. in the ringPointerTest.c we create some threads with the prio 0 and 1 ;-)
> Then they hang ...
Sure, the fallback to '0' works under linux where the main thread uses 
SCHED_OTHER. Under RTEMS, however,
the 'main' thread is IIRC a 'normal' SCHED_FIFO thread which has a 
priority higher than 0 and thus the true
ordering of priorities is different from what it seems.

The aforementioned changes may allow you to fix this, but IMHO, 
regardless or any decision (re. removal of the 'if ! isEpicsThread')
it might be better to change the test so that it uses epicsThreads only 
(by spawning separate threads for producer and consumer) because
ultimately that is the only guarantee that the two threads use the same 
scheduling policy (in a portable way).

- Till
> "ringPointerTest.c" line 171 of 248
>
> static void testPair(int locked)
> {
>      unsigned int myprio = epicsThreadGetPrioritySelf(), consumerprio;
>      pairPvt pvt;
>
> ...
> testDiag("single producer, single consumer with%s locking", locked?"":"out");
>
>      /* give the consumer thread a slightly higher priority so that
>       * it can preempt us on RTOS targets.  On non-RTOS targets
>       * we expect to be preempted at some random time
>       */
>      if(!epicsThreadLowestPriorityLevelAbove(myprio, &consumerprio))
>          testAbort("Can't run test from thread with highest priority");
>
>      epicsThreadMustCreate("pair", consumerprio,
>                            epicsThreadGetStackSize(epicsThreadStackSmall),
>                            &pairConsumer, &pvt);
>      /* wait for worker to start */
>      epicsEventMustWait(pvt.sync);
>