"Event driven" means that the application "sits there" waiting for events to drive what happens next. Typical events are various forms of mouse or keyboard activity.
In contrast, "process driven" (often "procedural programming") merely means that there's a program "watching" for things, constantly churning through whatever it is it's supposed to do.
You CAN code both at the same time, but doing so is "an advanced exercise" - or, at least, some think so.
Now, the big issue of race conditions is really all about the question of what entanglement may happen. With databases, here's a perfect example: If you code your return error status in a global varriable and there's ANY temporal overlap between activities in your code (often happens in "event driven" environments, but can happen in purely procedural programming, too) you can get the wrong error message. Imagine if a thread that made something happen had an error and a faster thread had no error, but the faster thread came afterwards, and set status to success; there's a condition that "thread safe" programming would avoid. This is but one example of a "race condition."
So long as each thread's actions are independent, you don't have race conditions per-se - it all depends on the application's logic and the needs thereof - and nobody here can tell you what they may be, only the developer! ...Is this an airline reservation system?...
