SA-MP Forums

Go Back   SA-MP Forums > SA-MP Scripting and Plugins > Plugin Development

Reply
 
Thread Tools Display Modes
Old 25/07/2013, 08:37 PM   #11
BigETI
High-roller
 
BigETI's Avatar
 
Join Date: Mar 2010
Location: Germany
Posts: 1,000
Reputation: 322
Default AW: Bcrypt

Ouch STL containers are not really thread safe. I've experimented with threads (from WINAPI) once, and it just accessed bad memory while the first thread was inserting information and the second one attempted to read it.

Also you are creating threads after the native function gets called. Realize your server attempts to call this native several times, and you are creating too many threads at once (again this can crash your application)
BigETI is offline   Reply With Quote
Old 25/07/2013, 09:22 PM   #12
Y_Less
Beta Tester
 
Y_Less's Avatar
 
Join Date: Jun 2008
Location: 629 - git.io/Y
Posts: 15,001
Reputation: 3151
Default Re: AW: Bcrypt

Quote:
Originally Posted by BigETI View Post
Ouch STL containers are not really thread safe. I've experimented with threads (from WINAPI) once, and it just accessed bad memory while the first thread was inserting information and the second one attempted to read it.

Also you are creating threads after the native function gets called. Realize your server attempts to call this native several times, and you are creating too many threads at once (again this can crash your application)
I agree with STL containers not being thread safe. In short, as eveyone knows, threads are hard. However, I don't see the issue with creating lots of them - it shouldn't crash your server unless you create thousands and thousands of them and run out of memory.
Y_Less is offline   Reply With Quote
Old 25/07/2013, 09:59 PM   #13
Johnson_boy
Huge Clucker
 
Join Date: Mar 2011
Location: Finland
Posts: 220
Reputation: 78
Default Re: AW: Bcrypt

Quote:
Originally Posted by BigETI View Post
Ouch STL containers are not really thread safe. I've experimented with threads (from WINAPI) once, and it just accessed bad memory while the first thread was inserting information and the second one attempted to read it.

Also you are creating threads after the native function gets called. Realize your server attempts to call this native several times, and you are creating too many threads at once (again this can crash your application)
I decided to test this by calling bcrypt_hash (work factor 12) 400 times with a for loop. The server did not crash and calculated the hash for each call. It might be that the server crashes if even more concurrent threads are created, but I really doubt that's going to happen under normal circumstances.


Edit: As to the issue with thread safety, what would you recommend as a solution? Based on quick research, the use of mutexes seems promising.

Last edited by Johnson_boy; 25/07/2013 at 10:38 PM.
Johnson_boy is offline   Reply With Quote
Old 25/07/2013, 11:25 PM   #14
Y_Less
Beta Tester
 
Y_Less's Avatar
 
Join Date: Jun 2008
Location: 629 - git.io/Y
Posts: 15,001
Reputation: 3151
Default Re: Bcrypt

I've used concurrent_queue in the past, but I think that only works for single-producer, single-consumer code, yours is multi-producer so I'm less sure. Mutexes would work though, but make sure you use lightweight ones (pthreads or CRITICAL_SECTION).

As I said, check the SQL plugins. I know Dan.'s has an abstracted lock system.
Y_Less is offline   Reply With Quote
Old 26/07/2013, 03:09 AM   #15
Red_Dragon.
High-roller
 
Red_Dragon.'s Avatar
 
Join Date: Sep 2012
Posts: 1,401
Reputation: 46
Default Re: Bcrypt

Happy to see this finally in a plugin!
Red_Dragon. is offline   Reply With Quote
Old 26/07/2013, 07:12 AM   #16
Dan..
Gangsta
 
Join Date: Jun 2012
Location: Galati, Romania
Posts: 521
Reputation: 122
Default Re: Bcrypt

Suggestions:

http://www.boost.org/doc/libs/1_54_0...free.queue_hpp

Don't use more than 2 threads.

Implement a blocking function aswell for those having powerful servers.

Make `cost` a default parameter. Also, playerid parameter is useless, you'd better add an "threadidex" parameter.
pawn Code:
native bcrypt_hash(threadid, threadidex, password[], cost = 4);
Also, this means that you have to change the callback:
pawn Code:
forward OnBcryptHashed(threadid, threadidex, password[], hash[]);
__________________
I'm no longer visiting these forums. BlueG, you can suck my dick.
Dan.. is offline   Reply With Quote
Old 26/07/2013, 07:20 AM   #17
Niko_boy
High-roller
 
Niko_boy's Avatar
 
Join Date: Aug 2010
Location: Somewhere i belong
Posts: 1,423
Reputation: 138
Default Re: Bcrypt

nice another hashin implementation
good will give ti a shot!
__________________
nope[IMG]http://*******/1r0SOkH_[/IMG]
•••[CLOSED]LCS•Freeroam•DM•Stunts•••AutoArena [0.3z][No SkinShot][sixtytiger.com]Want a decent Attack Defend Gamemode?
N/A176.31.229.148:7830Get This! Attack-Defend(v2.3.1)
Niko_boy is offline   Reply With Quote
Old 26/07/2013, 05:23 PM   #18
Johnson_boy
Huge Clucker
 
Join Date: Mar 2011
Location: Finland
Posts: 220
Reputation: 78
Default Re: Bcrypt

I decided to use std::lock_guard to overcome the issue with vector's thread safety. It seemed the most suitable and secure solution (unlocks even on exceptions)

Quote:
Originally Posted by Dan.. View Post
Suggestions:

http://www.boost.org/doc/libs/1_54_0...free.queue_hpp

Don't use more than 2 threads.

Implement a blocking function aswell for those having powerful servers.

Make `cost` a default parameter. Also, playerid parameter is useless, you'd better add an "threadidex" parameter.
pawn Code:
native bcrypt_hash(threadid, threadidex, password[], cost = 4);
Also, this means that you have to change the callback:
pawn Code:
forward OnBcryptHashed(threadid, threadidex, password[], hash[]);
Thanks for the suggestions.

I added the default cost and changed playerid to thread_idx.

About limiting the amount of threads used to 2: Why should this be done? Does it increase stability?
Johnson_boy is offline   Reply With Quote
Old 26/07/2013, 05:38 PM   #19
Y_Less
Beta Tester
 
Y_Less's Avatar
 
Join Date: Jun 2008
Location: 629 - git.io/Y
Posts: 15,001
Reputation: 3151
Default Re: Bcrypt

No, I think what Dan.. meant was that the Boost library he suggested for lock-free communication only works between two threads, but you chose a different method so that doesn't matter.
Y_Less is offline   Reply With Quote
Old 26/07/2013, 06:27 PM   #20
Dan..
Gangsta
 
Join Date: Jun 2012
Location: Galati, Romania
Posts: 521
Reputation: 122
Default Re: Bcrypt

The amount of resources wasted creating a new thread, executing it parallelly, collecting the result (there is a mutex that will waste a little more), sending it back to the main thread, killing the thread is way too big. You shouldn't need more than two threads (SA-MP's ProcessTick - to communicate with the AMX and another one for computing).
__________________
I'm no longer visiting these forums. BlueG, you can suck my dick.

Last edited by Dan..; 27/07/2013 at 07:51 AM.
Dan.. is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



All times are GMT. The time now is 12:38 PM.


Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.