Re: Perl should start to specify which function and module are thread-safe

Tie::File is a bit different from a standard library function. The reason strtok isn't thread-safe is that it stores data in an internal static variable that is shared by the whole process, and isn't thread-local. The usual way to make something like this thread safe is to either eliminate the buffer or make the user of the function pass in the buffer to be used, allowing them to make sure its thread-local. This means that the function itself doesn't contain any thread-handling code, and places this burden on the user.

The difference between Tie::File and a library function is clear. Tie::File explicitly stores information between calls. Once you know that Tie::File stores data and doesn't use locking, it should be immediately clear that using it without your own locking on the variable is not thread-safe.

If you're using threads it should be the responsibility of the user to handle locking on shared variables as this allows consistency across their application and they can handle the hard bits like dead-lock resolution.

--
integral, resident of freenode's #perl

Comment on Re: Perl should start to specify which function and module are thread-safe

Replies are listed 'Best First'.
Re: Re: Perl should start to specify which function and module are thread-safe by pg (Canon) on Feb 02, 2003 at 20:24 UTC
I understand what you said and fully agree with you. Your comment definitely made this thread more complete. However the situation here is a little bit more complex than what you just stated. From my application point of view, locking is not a problem. As you can see, I didn't use any lock at all, because each child thread will only access that array element belongs to it, so lock is not required from my point of view, or to be precise, my application's point of view. Now as for the internals used by Tie::File. I don't care, and I SHOULD NOT care. Although I read the code of that module before, but that is not required for using the module, thus there is no way to require the user to help lock Tie::File internals, as he/she most likely has no appreciation of what is going on in that module. If my logic requires some lock, the only thing I would and I am supposed to lock is @array, not any Tie::File internals. As for those Tie::File internals, if the author wants to make his package thread-safe, go do something, redesign it, apply lock whenever it is required ... Yes, to make a OO module thread-safe is a much bigger challenge than to make a usual function thread-safe, and this is my experience with c++ classes and pthread. This is for sure, and this most likely would require fundamental changes to Perl OO, (and I am thinking probably even the way perl variables are scoped, especially the main:: scope)	[reply]
Re: Re: Re: Perl should start to specify which function and module are thread-safe by integral (Hermit) on Feb 02, 2003 at 20:32 UTC
My point of view is that it should be the job of the module writer to guess every possible situation of when a object. And this applies fine was a simple object like the Employee or Person often used in OO tuts. But it begins to break down when you get objects which could benefit from higher-grain locks. My approach would not to include locking in the core modules since this increases overhead in the large number of applications with threads, but to instead use an adaptor or subclass to wrap locks around each record and to manage them. You make a good point that by encapsulation you shouldn't need to know about locking, but surely the core algorithms for mapping a file to an array don't need to know about thread locking? This would be best served by adding another layer on top of the existing class. -- integral, resident of freenode's #perl	[reply]