News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

speed question

Started by ecube, September 02, 2008, 05:05:43 AM

Previous topic - Next topic

ecube

when I try and use any implementation of rc4,rc5,rc6, aes etc etc in asm, for some reason the encrypt/decrypt algoritms don't en/decrypt the data fast enough and it messes things up on the other side. I've tossed in Sleep(400) after there calls which helps alil bit, but my question is, why the delay? the algs are suppose to do what they do with each byte *THEN return, I don't get why they're returning before whatever it's suppose to do is fully finished. And this speed problem and returning too early isn't just for these algs i've had this problem in masm awhile, code returning sooner than it should and I honestly don't understand why.

hutch--

cube,

While encryption is not really my field, there are a few basics in how you test this stuff that are useful with any algo. Set up a test where you know what you put in at one end (encrypt the data) then test it against when comes out the other end (decrypt the data.

Normally the target is to get the same out as you put in. If this is not happening you need to break down the algo and see if its doing what it was designed to do.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

jj2007

Quote from: E^cube on September 02, 2008, 05:05:43 AM
code returning sooner than it should

Spooky :dazzled:

mov eax, 123
.if DontLikeValue ret sooner
mov eax, 456
ret


ecube

you're misunderstanding what i'm saying, let me give you another example that's probably similiar


invoke createthread etc... now once I call this function I assume I could just move on as the function is called nothing else for me to do here...unfortunately that's not the case, and every example including icezlions that just called createthread, and moves on isn't correct because i've found sometimes the function called in createthread doesn't get its params...i'm not sure why but I fixed it by specify a structure as a param and waiting till one of its values have been filled indicating everythings ok until I continue on with my program, perhaps someone here can explain this situation, maybe it'll help me understand why other functions i've written used don't work correctly unless I add in a invoke sleep after...

Tedd

So your problem is with multi-threading, not the algorithms themselves :wink

When you call CreateThread, it creates the new thread (as the name suggests ::)), but when that thread actually gets scheduled and starts running is down to the Windows scheduler, i.e. I don't think it's guaranteed that the thread has started when CreateThread returns.
I'm guessing at how the scheduler actually works, but each process will get a time-slice, and then a thread in that process will be run. If that thread blocks, either another thread in that process can be run, or the whole process blocks until its next time-slice (when another thread will be run.)
So, when your program starts, it's your main thread (call it thread A) that's running. Then you call CreateThread and get thread B in your process. At this point A is still running, while B is ready and waiting to be run. At some point A will block, which gives B a chance to run (though not necessarily in this slice.) Another slice later and B might have finished its stuff and A can run again... and so on.
In short, you have no idea of which thread will be run, or when. Fantastic :bdg

If you call Sleep, that will block your thread - so then B gets a chance of running.
Your solution of waiting on a shared flag will work (though I would wait until the LAST param is filled, rather than 'any'), but leads to a polling loop. A can check the flag, and then Sleep again if it's still not ready. In testing this exact thing some time ago, it turns out that even with this, A could still end up sleeping numerous times before B gets done (and all B was doing in my example was setting the flag.)
The alternative is to use one of the synchronisation primitives - either an Event or Mutex, in this case - which are meant for this exact purpose (it's a classic problem.) Thread A can then block and won't be re-scheduled until B has done its stuff. Strangely though, it seems to take slightly longer (in real time) for the operation to complete (probably due to other processes eating up time-slices.)
No snowflake in an avalanche feels responsible.

jj2007

Quote from: E^cube on September 02, 2008, 10:16:23 AM
you're misunderstanding what i'm saying

Deliberately - your question became much more understandable afterwards :U
Thanks also to Tedd for a detailed answer, I keep learning. But now a stupid question: Why a new thread? Why don't you just invoke the algo and wait until it's finished?

hutch--

cube,

I have posted examples in the past to make sure the thread gets the arguments before it caller terminates. In the called write a spinlock loop that exits when the args are copied to locals in the new thread. You can use a global to do it or if you can be bothered pass a structure to the new thread with the address of a local in the caller. In the spinlock loop, put a "invoke SleepEx,0,0" so that the new thread starts faster.

Look at the example in masm32 version 10 for the file \masm32\example10\threads\multidl.asm for the technique.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

PBrennick

You can also start Thread B and go into a wait loop (not Sleep). It would be Thread B's responsability to get the address of the parent thread and set a flag in the parent thread that would tell it to stop waiting. the advantage of this, is, since as Michael hasn said so well, the wait period is indeterminate, but you will know for sure when it starts.

So, Thread A starts Thread B and waits for a callback telling it it that Thread B is executing which means it has all of its parameters. Very simple, really.

-- Paul
The GeneSys Project is available from:
The Repository or My crappy website

Mark Jones

Also look into the CriticalSection API's. With CreateThread, it is possible to create them suspended, and have them respond to events.

Multithreading! (whoa what just happened?) Welcome to the wonderful world of...
"To deny our impulses... foolish; to revel in them, chaos." MCJ 2003.08