If you are using STM32 you probably have the possibility to mask specific interrupts. If you are sure that only the task and the gyro interrupt are the two "threads" accessing this shared memory you could just mask the gyro ISR. This way all the other interrupts would still be allowed to interrupt, but access to the shared memory is still "atomic".
I don't know what specific MCU/CPU you are running, but the register to mask bits in on Cortex-M3/4 is called:
$$EXTI->IMR$$
EDIT:
The doc states on page 69:
"If a critical section is accessible by an Interrupt Service Routine (ISR) and a task, then disabling interrupts is necessary to protect the critical region."
This is usually the case, unless you can somehow else guarantee that the ISR that have access to the shared data does not get triggered.
When you use the uC/OS-III OS_CRITICAL_ENTER() and OS_CRITICAL_EXIT() I assume they call the global interrupt disable/enable, but as I mentioned over, you can mask and disable the interrupts that have access to this shared data before accessing this data then enable it again when done accessing the shared data.
There are other ways to do it as well. If you have a ring buffer and maybe some index variables you can use OS_CRITICAL_ENTER() right before you read the index variables (which are shared memory) to a local variable and OS_CRITICAL_EXIT() after. The ring buffer does not need to be copied as you will not access the same memory address at the same time assuming the ISR write data and the application code read data. Copying to the local variables will only take a few cycles so the chances of interrupts are very very low during this time. I also think that most of the ARM MCU/CPU save one interrupt of each type (the specific interrupt flag bit) and when you call OS_CRITICAL_EXIT() they will get served. If it happen that two of the same interrupts got triggered during the local variable copying, one will get lost, but this is highly unlikly.
Best Answer
You could use your existing interrupt to increment a counter. You should know the period of your existing interrupt already, so divide your required time by that period and that's the number of counts of your counter you need to check for.
For instance, if your multiplexing interrupt happens once every 5ms and you need to wait 10 seconds, then you would wait for your counter to count up to (10 / 0.005 = ) 2000. When you see your counter exceed that value you would then reset the counter and perform your periodic tasks.