If I have an event that happens every 100 uSec how do I hadle this. Do I have an interrupt that works seperate from the RTOS that will suspend the RTOS for a period or is there a better way???

Yes, for something that fast you are better using traditional interrupts.

In general, this sort of event will be generating an interrupt. In fact, I find that MOST events start off as an interrupt (we want to avoid the case where the program needs to periodically scan around the hardware looking for a flag that has been set).

Once that interrupt occurs, you have two primary choices of how to proceed. The first is to all the work to handle that interrupt inside the interrupt routine. The second is to do the minimum amount of work to get the information about the interrupt, and pass that data to a task, which will finish up the work required to handle the event.

The first case, doing it all in the interrupt, can be appropriate if the work needed to be done is quick, or is very urgent. The big problem with doing this, is that code running in an interrupt will normally be blocking some other interrupts from occurring.

The second case, sending the data to a task, gets around this problem, as the interrupt routine blocks the interrupts for only a short period of time. If the task that it sends the information to is the highest priority task available, then the flow of execution between the two is very close to the same, with primarily a quick trip though the scheduler added.

There are also possible cases in between, where the interrupt does maybe a bit more work, and can perhaps finish processing a lot of cases, and then switches to the task only sometimes (for example, buffering up data and releasing an assembled message buffer).

Which method is best depends a lot on the details of the system. If you can process the event in just a few uSecs, then doing it in the interrupt makes sense. If it is going to take 70uSecs, then switching to a task probably makes sense. (If it takes 99.9 uSec, and switching to a task is too expensive, you need more processor). The middle ground of things like 10 uSec, put you into the case of needing to know what sort of latency your other interrupts can tolerate, and if any other critical interrupts can nest over this one.