PHP多线程 - 安全吗[关闭]

Question

[EDITED]

BACKGROUND: I am considering using pthread package in a CLI app under linux. I found many heated debates about the status of thread safety and on balance it looks like something to avoid due to the inherent non thread-safe nature of many php functions.

But from this docs page: "Thread Safety works by creating a local storage copy in each thread, so that the data won't collide with another thread". This would seem to 'fix' the problem and obsolete much of the old information (even if the actual php code has not been rewritten).

QUESTIONS:

a) Has the current php thread safety model been demonstrated to be not safe for any reason?

b) There must be speed and memory hits loading the interpreter into every thread -- any statistics available?

PLEASE: No opinions, educated or otherwise, just demonstrable, up-to-date, data.

Answer 1

Full Disclosure: I'm an internals contributor, and I wrote pthreads.

The first release of PHP with a threading model was on 22nd May 2000, the arrival of PHP4.

There were teething problems, not caused by the theory of model at all, but by code that broke the model; For example, the invocation of non re-entrant functions.

The invocation of non re-entrant functions can still pose a problem; It doesn't matter what model the calling code uses if the callee is going to ignore it, and do something like use globally shared or static state.

In the year 2000, it wasn't so common-place for libraries or functions to be re-entrant by default as it is today. Primarily because non-embedded multi-core systems weren't generally available until later in the naughties.

Nowadays it is common-place for the default version of a library to be re-entrant, or as in the year 2000 provide a re-entrant version.

These teething problems are a distant memory in the year 2015.

PHP is composed of many modules, from the allocator and the executor, to the standard library, and all the extensions that are thin wrappers around third party libraries.

Thread safety is actually achieved by ensuring that each thread has a unique copy of all module globals.

So threads operate in different regions of memory entirely, which is not like a normal multi-threaded application at all.

They can technically share, but they don't: Share Nothing.

Can the naysayers be finally put to bed?

Yes, there is no debate; PHP has a robust, proven, thread safety model.

There must be speed and memory hits loading the interpreter into every thread -- are they noticeable?

Yes, you can measure it, nothing happens for free.

However, the alternative is to share module globals between threads.

Module globals are extremely high frequency, referenced on allocation, free, print, fetch object, fetch resource, and a million things besides.

If they were shared, you would need to synchronize access to them, introducing huge contention for locks, in addition to an enormous number (somewhere between millions and tens of millions) of additional instructions per request.

The alternative would cripple PHP.

In reality, the cost of a separate interpreter is just the cost of initializing separate module globals, and when you consider the alternative, it is extremely cheap.

At no time does pthreads break the threading model of PHP, even when it appears to, it cannot.

That's all there is to say about that.