Just enough to be dangerous (on threads) indeed! :-)

In Unix when you fork you usually wind up communicating between the processes in a pipe. With threads the two can communicate directly through an internal buffer (they share the same memory). With Unix you don't have to worry about how you use data, but there is more overhead. With threads you do have to be careful because the threads can trample over each other, but you can get better performance.

Where locking is necessary is when two things (threads, processes, machines in a cluster, whatever) need to synchronize access to the same resource. Think here of Highlander - allow only one invocation at a time of an expensive CGI script, or also think of some CGI script that updates some user file. If your user submits twice you now have 2 processes, one of which might be reading while the other is deleting...

That is a race condition. If the first cleanly read, rewrote, and exited, you would be fine. The second likewise. If they collide...

It just happens to be really easy for two threads to collide. And much less common for programs to do it.

Comment on Just enough to be dangerous (on threads) indeed! :-)

Replies are listed 'Best First'.
RE: Just enough to be dangerous (on threads) indeed! :-) by lhoward (Vicar) on Aug 25, 2000 at 22:27 UTC
> With threads the two can communicate directly > through an internal buffer (they share the same memory). You can do this with separate processes by using SysV IPC. > With Unix you don't have to worry about how > you use data, but there is more overhead. With > threads you do have to be careful because > the threads can trample over each other, > but you can get better performance. And you gain (just about) all the benefits (and problems; plus a few new ones) of threads when you use SysV IPC. Not coming down on tilly, just bringing up an alternative.	[reply]
RE (tilly) 2: Just enough to be dangerous (on threads) indeed! :-) by tilly (Archbishop) on Aug 25, 2000 at 22:33 UTC
Ack! I knew that as well. It is just that fork() is so much a Unix idea that I think of it as "the Unix way" even though Unix also has many other ways of working. Incidentally on machins that support it, you can use shared memory from Perl with IPC::Shareable.	[reply]
RE: RE (tilly) 2: Just enough to be dangerous (on threads) indeed! :-) by lhoward (Vicar) on Aug 25, 2000 at 22:59 UTC
I find IPC::Shareable extermely handy. Very frequently I want programs to be able to exchange some pieces amounts of data; and I want them to do it quickly. Files are too slow and "real" TCP/IP networking can be a hastle for just sharing a little data. Also when the processes aren't related (i.e. they wouldn't fork to create each other under the processes model ; they wouldn't be separate threads under the therading model) it is just really handy to use IPC::Shareable. Its just that so many people think its either "pipes or TCP/IP" when their processes need to communicate. SysV IPC is extremely apropriate for some problems.	[reply]


Think about Loose Coupling
	PerlMonks