[botan-devel] Threaded Filters/Operation Parallelisation

Jack Lloyd lloyd at randombit.net
Wed Jan 2 10:49:14 EST 2013


Hi Joel,

I've only had time to very briefly review the patch but it looks good.

A few minor comments:

- Can you use an m_ prefix on all class members? I know a lot of the
  code doesn't use a prefix or suffix at all, but I am trying to
  ensure that all new or heavily touched code adopts m_ (rather than
  suffix _ as you use in Semaphore or no prefix).

- Semaphore seems generally useful, move it to src/util/semaphore.{cpp,h}

- Add your name to the copyright headers of each modified file. (And
  make sure all new sources have one)

- For some reason, despite all your work on Windows support and other
  patches, your name is not already included in the list of copyright
  owners in the license, so please also update license.rst

Can you make those changes and send the updated patch as an attachment
to the list (so it can be archived by mailman)?

Thanks,
  Jack

On Wed, Jan 02, 2013 at 06:51:10AM +0000, Joel Low wrote:
> Hello all,
> 
> So I've finally managed to sit down and write this patch. The design seems
> quite different from what I had in mind, since this round I wanted it to be a
> drop-in replacement for Fork.
> 
> There's a bit of code taken from a blog post to emulate a semaphore: The link
> is there, and if someone knows of a better class (or better still, one within 
> Botan itself), let me know and I'll use that class instead.
> 
> Let me know what you think.
> 
> Patch: http://pastebin.com/kgF0b7Yp (1 month visibility)
> 
> Regards,
> Joel
> 
> -----Original Message-----
> From: botan-devel-bounces at randombit.net
> [mailto:botan-devel-bounces at randombit.net] On Behalf Of Joel Low
> Sent: Tuesday, 24 April 2012 5:07 PM
> To: botan-devel at randombit.net
> Subject: [botan-devel] Threaded Filters/Operation Parallelisation
> 
> Hello all,
> 
> Recently I've been playing with the idea of having a threaded Fork filter to
> be used together with Pipe: processing for each subsequent filter downstream
> of the threaded Fork filter is done in a separate thread of its own. This
> could potentially bring performance benefits (in theory) especially with a
> move on to having an increasing number of computing cores per CPU.
> 
> So I've emailed Jack separate to the list to get some of his opinions. The
> main points he raised were that:
> 
>  - The approach used for Fork would be most promising in terms of working
> with the current design and not forcing a full rewrite of the filter system.
>  - He proposed defining a new Filter subclass Threaded_Filter which itself
> takes a Filter* as an argument which will spawn a thread and uses two
> message queues for I/O with the filter it manages.
>  - When write() is called on the Threaded_Filter, it pushes it to the input
> queue, which the worker thread pulls off and write()s to the underlying
> filter.
>  - With this approach the application can control concurrency very finely
> (perhaps too finely), since the application can specify which filters run on
> the main thread, and what runs on a secondary thread.
> 
> I was leaning to a slightly different approach: with the knowledge that Fork
> operations parallelise the easiest, I should adapt the Fork class to let
> each downstream filter run in a separate thread. This shares much
> commonality in its design with Jack's idea (especially in terms of thread
> sync and friends), provides a little less control over what runs in a
> separate thread, but comes with a slightly easier implementation.
> 
> Jack stated that I probably should email the devel list and solicit ideas,
> since everyone may have different expectations. I'll be implementing this in
> my spare time so I'd like to accept as many ideas and combine them before
> acting on it. I think that the pipe/filter design Botan has is intuitive,
> and I'd like to keep that as much as possible, without compromising on
> potential performance gains. Intuitively, both seem to run contrary to each
> other, but I think we can work something out here to an API that is both
> powerful yet easily mastered.
> 
> Any thoughts?
> 
> Regards,
> Joel
> 



> _______________________________________________
> botan-devel mailing list
> botan-devel at randombit.net
> http://lists.randombit.net/mailman/listinfo/botan-devel




More information about the botan-devel mailing list