[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 17 Aug 2015 16:04:12 -0500
From: JimF <jfoug@....net>
To: john-dev@...ts.openwall.com
Subject: Re: Sybase-PROP (Re: FMT_OMP_BAD)
On Mon, 17 Aug 2015 15:51:56 -0500, Solar Designer <solar@...nwall.com>
wrote:
> On Mon, Aug 17, 2015 at 03:29:58PM -0500, JimF wrote:
>> I am surprised that it worked at all, with the static's the way they
>> were.
>
> Why, it's multiple threads writing the same data to the same locations.
> It's just that reads and writes from/to "First" needed the corresponding
> memory barriers.
Looking now, it looks fine. The 'First' value was set after modifications
to the array so a 2nd thread would simply enter the loop and also produce
the same values in the array. I was thinking that the semaphore flag was
set early in the loop, which would allow another thread to start using
the array of data before it was properly setup.
But yes, any time there are static/global data in threaded functions, you
have to look VERY careful at how they are accessed, and it almost always
ends up in problems and or even incorrect results. In dynamic, I use
globals all over the places (allocated statics), but they are known size
buffers, and I simply give each thread a 'range' to own from within
those global buffers. So in that case, thread 0 may get index 0 to 119,
which would give it 10 blocks of SSE2 MD5 with PARA=3. the next thread
would get index 120 to 239, etc. It is all global stuff, but it is
properly cooperatively used.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
