Two tasks have the same priority and both are ready. What happens?

Pure priority scheduling can't break the tie, so a typical RTOS like FreeRTOS uses round-robin time-slicing among equal-priority Ready tasks: each runs for one time slice (one tick by default) and then the scheduler switches to the next equal-priority task, cycling through them fairly. So the two tasks alternate, sharing the CPU roughly equally as long as both stay Ready and nothing higher-priority preempts them. This is controlled by a config option (configUSE_TIME_SLICING); with it disabled, an equal-priority task could run until it blocks. The important framing is that this round-robin only applies within the highest-occupied ready priority level, priority still dominates, so a higher-priority task always beats both of these, and these two only share the CPU because they're tied at the top of the ready set. The practical caution is that piling many tasks at the same priority turns your carefully-prioritized system into a fair-share round-robin, erasing the prioritization and adding context-switch overhead per slice, so you use distinct priorities where execution order actually matters and reserve equal priorities for genuine peers.