Re: [boost] Mutexes claim a Windows event handle

Subject: Re: [boost] Mutexes claim a Windows event handle
From: Peters, Richard (richard.peters_at_[hidden])
Date: 2010-06-03 07:50:49

> 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.