Re^2: Program Design Around Threads

When they have it, they lock the shared hash and add the content (or an error messgae) as the value, keyed by the id.

The outputter thread monitors this hash waiting for the appearance of the next id in sequence, and when it appears, they lock the hash; write it to the file and then delete it.

What is the point of the locks? The id's are unique, right? As far as I can tell, it doesn't matter if every thread--including the outputter--all modify the hash at the same time.

Comment on Re^2: Program Design Around Threads

Replies are listed 'Best First'.

Re^3: Program Design Around Threads
by BrowserUk (Patriarch) on Mar 06, 2013 at 07:38 UTC

What is the point of the locks? The id's are unique, right? As far as I can tell, it doesn't matter if every thread--including the outputter--all modify the hash at the same time.

Primary reason is that getters add key/value pairs to the hash; and the outputter removes key/value pairs from the hash. These are substantive modifications to the hash structure.

It may be that Perl's internal locking is sufficient to ensure that the key cannot be seen before the value is also available, but if that is the case, the additional locking will incur very little overhead as it will be released at almost exactly the same time as the internal lock.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

[reply]


"be consistent"
	PerlMonks