> On 09/06/2012 07:52 PM, Tom Breton (Tehom) wrote:
>> I've moved the read lock in MappedEventBuffer::peek into
>> MappedBufMetaIterator functions so that it covers the entire scope
>> during
>> which the MappedEvent pointer is exposed. It's not perfect, because
>> caller has to know to do that, but it's much better than my first
>> solution.
>
> Thanks, Tom, all this stuff you've been doing looks really good.
Thanks.
> Would it be possible to make a copy of the event in order to reduce
> the time that it is locked? Just a random thought. Not sure if making
> a copy even makes any sense.
That was definitely an alternative I had in mind. IMHO it isn't worth it
on the balance. Here are some points I considered:
* That would be cleaner.
* There's no threat of future modifications innocently holding a pointer
past the scope of the lock.
* If we did that, we'd generally be allocating the MappedEvent (or
something resembling it) twice, because the inserting end really wants to
do the allocating itself so that it has full control for flexibility.
Eg, the MidiFile stuff actually inserts another kind of object, and the
channel code inserts not only (a copy of) the MappedEvent we give it but
sometimes other MappedEvents to set up the channel. That could be
finessed at the cost of some added trickiness.
* Sometimes events are merely skipped by later tests after peek() gives
us them. Eg for muted tracks, or events that will be played in a later
slice, which actually make up the majority of events that the inner loop
sees if my music is at all typical. If we allocated it in peek() or
immediately after, we'd just have to delete most of them again without
ever using them.
* The MappedBufMetaIterator inner loop is a hot spot, so I'm reluctant to
add an avoidable allocate+delete to it.
* We can only get a conflict when we're reading and writing at coarsely
the same time, ie the user is editing stuff while playing. That use case
is considered less crucial than playing smoothly while nothing is being
jiggled.
* We're only locking it against resizing the buffer, everything else gets
through.
> Just seems like with all the
> multi-threading stuff I've been reading, it's not uncommon to copy some
> data to reduce locking periods. I've unfortunately had little
> opportunity to work with multi-threading. Hoping to get more into it
> soon.
I know just what you mean. I hadn't seriously wrestled with
multi-threading before Rosegarden either, though of course I knew about it
in theory.
Tom Breton (Tehom)
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
