Anthony Williams wrote:
Richard Peters wrote:
I could understand if a recursive_mutex costs a handle, except that in boost 1.34 they didn't so I wonder if this was an accident or a deliberate change. And most important: Is there a way to get the same behavior as in 1.34 where a mutex did not cost me one handle each?
No, there is not.
Why do you need so many mutexes?
Yeah, as a threading non-expert but somewhat educated bystander, what Richard described smells like a design with many locks at object granularity, which is almost always a mistake. Have you considered revisiting the architecture?
I'll explain our architecture at a high level, and see if we can come up with a better way of locking. Those 100.000 'objects' are in fact print jobs in a print controller. Each job contains the structure describing what the job looks like (sheets and pages and such, among with their attributes like stapling or how the bitmaps should be rotated), stuff for maintaining progress and accounting, a pipeline of objects doing all sorts of manipulations like making it a duplex job or creating booklets of it, etc. A job is constructed by either ripping a document (for instance postscript) or by scanning a document. This ripping or scanning is kind of repeated after a user edited the job on the user interface. All the while, the printer wants to get information from the job, in order to be able to print the job while it's still ripping. Now in this job we have a few mutexes for , but a single mutex for all jobs together doesn't cut the case either: a job which is scanning might be busy with building a booklet (which is a time-consuming operation), and all the while printing of another job must be able to continue. Anyway, we ran tests with boost 1.34, and indeed, that version also consumes as much handles. We also found that we overestimated our maximum job capacity, at about 10.000 jobs, our memory is full, and the number of handles is not yet critically high. Any ideas of how to reduce our number of mutexes would be welcome, though. best regards, Richard This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.