Hi,
Lane and I were looking at TranslationOptionCache which is currently
correctly but inefficiently locked.
We need a threadsafe hash table. There's Intel Threading Building
Blocks, Facebook Folly, or https://code.google.com/p/nbds/ . I know
Facebook Folly requires knowing the size in advance.
Another option is a fixed-size array where each element contains a hash
table and a read-write mutex. Then there would only be lock contention
within each element. This is effectively a two-level hash table.
Kenneth
On 09/10/12 15:12, Marcin Junczys-Dowmunt wrote:
> Hi Hieu,
> ok, I will take a close look a that.
>
> Kenneth, Lane, how does this interfere with your
> thread-local/non-locking plans? I do not want to introduce code that you
> will have to remove later in order to reach your goal.
>
> W dniu 10.09.2012 16:01, Hieu Hoang pisze:
>> hi marcin
>>
>> > Funnily, there is also no locking in the AlignmentInfoCollection
>> class itself although is uses a global static collection. But it has a
>> very> nice comment: "@todo Check whether this needs locking in threaded
>> environment" :) I'd say "Yes!".
>>
>> i added this @todo comment a few months ago but haven't gotten round to
>> checking it or fixing it. If you're able to fix it, that'll be great. I
>> think the locking in FactorCollection would be a good comparison.
>>
>> this issue is prob why the chart decoder blows up with multiple-threads
>> so you'll be hitting 2 birds with 1 stone with a fix
>>
>> _______________________________________________
>> Moses-support mailing list
>> Moses-support@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>
> _______________________________________________
> Moses-support mailing list
> Moses-support@mit.edu
> http://mailman.mit.edu/mailman/listinfo/moses-support
_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support
