The only thing you should ask yourself is: Are you really expecting so much traffic on your site to warrant such a complicated and risky setup (as opposed to "regular" prefork + php as a module).
I've been running a couple of php heavy sites peaking at 10m+ hits/day without having the need to switch to threaded model. PHP per se is a mess, making it jump through hoops is asking for it.
The PHP FAQ explicitely states this is a bad idea. Most libraries it depends on are indeed no thread safe.
If you wish to use Apache worker (I sure do, personally), you might want to investigate running the worker-mpm and PHP5 with FastCGI (mod_fcgid) instead.
The "cgi" part might put you off, but rest assured, mod_fcgid results in great performance, it uses a process pool, where PHP gets its own memory space, completely independent of the web server. This has multiple advantages, including to but not limited to better security (you can run the pool as a different user), better stability (if PHP crashes, it won't take your webserver down with it) and significantly reduced memory for apache processes since they don't have to embed mod_php at all, they just communicate with the pool. It also allows for some unprecedented granularity because of this.
Here's an example tutorial for Debian based systems. I use it in production for various systems, it allows me much more scalability.
Best Answer
PHP can be thread-safe if you don't use non-thread-safe extensions. See this page for information on thread safety and checking that your PHP variant is thread safe for use with Apache. And have a look here if you need help choosing between thread-safe or non-thread-safe editions of PHP: it depends on the Apache worker and how it handles requests (in terms of threads, processes, etc.).