Click here to Skip to main content
11,577,522 members (37,494 online)

Pablo Aliskevicius - Professional Profile





Summary

Google+  LinkedIn      Blog RSS
14,683
Author
4,800
Authority
901
Debator
62
Editor
38
Enquirer
723
Organiser
2,125
Participant
Pablo writes code for a living, in C++, C#, and SQL.

To make all that work easier, he uses some C++ libraries: STL, ATL & WTL (to write Windows applications), and code generation.

Pablo was born in 1963, got married in 1998, and is the proud father of two wonderful girls.

Favorite quotes:
"Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, "The Devil's Dictionary", published in several newspapers between 1881 and 1906).
"You are to act in the light of experience as guided by intelligence" (Rex Stout, "In the Best Families", 1950).
  • 18 Oct 2013: Best C++ article of September 2013

Articles 7 (Legend)
Tech Blogs 0
Messages 252 (Regular)
Q&A Questions 0
Q&A Answers 166
Tips/Tricks 2
Comments 133

Reputation

For more information on Reputation please see the FAQ.

Privileges

Members need to achieve at least one of the given member levels in the given reputation categories in order to perform a given action. For example, to store personal files in your account area you will need to achieve Platinum level in either the Author or Authority category. The "If Owner" column means that owners of an item automatically have the privilege, and the given member types also gain the privilege regardless of their reputation level.

ActionAuthorAuthorityDebatorEditorEnquirerOrganiserParticipantIf OwnerMember Types
Have no restrictions on voting frequencysilversilversilversilverAdmin
Store personal files in your account areaplatinumplatinumSitebuilder, Subeditor, Supporter, Editor, Staff
Have live hyperlinks in your biographybronzebronzebronzebronzebronzebronzesilverSubeditor, Protector, Editor, Staff, Admin
Edit a Question in Q&AsilversilversilversilverYesSubeditor, Protector, Editor, Admin
Edit an Answer in Q&AsilversilversilversilverYesSubeditor, Protector, Editor, Admin
Delete a Question in Q&AYesSubeditor, Protector, Editor, Admin
Delete an Answer in Q&AYesSubeditor, Protector, Editor, Admin
Report an ArticlesilversilversilversilverSubeditor, Mentor, Protector, Editor, Staff, Admin
Approve/Disapprove a pending ArticlegoldgoldgoldgoldSubeditor, Mentor, Protector, Editor, Staff, Admin
Edit other members' articlesSubeditor, Protector, Editor, Admin
Create an article without requiring moderationplatinumSubeditor, Mentor, Protector, Editor, Staff, Admin
Approve/Disapprove a pending QuestionProtector, Admin
Approve/Disapprove a pending AnswerProtector, Admin
Report a forum messagesilversilverbronzeProtector, Editor, Admin
Approve/Disapprove a pending Forum MessageProtector, Admin
Create a new tagsilversilversilversilverAdmin
Modify a tagsilversilversilversilverAdmin

Actions with a green tick can be performed by this member.


 
GeneralOn global pointers. Pin
Pablo Aliskevicius4-Apr-12 19:42
memberPablo Aliskevicius4-Apr-12 19:42 
GeneralThe programmer as an artist Pin
Pablo Aliskevicius12-Sep-11 23:09
memberPablo Aliskevicius12-Sep-11 23:09 
GeneralRe: The programmer as an artist Pin
Aniruddha Loya14-Nov-11 21:29
memberAniruddha Loya14-Nov-11 21:29 
GeneralThere is no such thing as quick and dirty. Pin
Pablo Aliskevicius30-Mar-09 21:30
memberPablo Aliskevicius30-Mar-09 21:30 
GeneralRe: There is no such thing as quick and dirty. Pin
ThatsAlok 18-Jul-11 22:57
member ThatsAlok 18-Jul-11 22:57 
GeneralRe: There is no such thing as quick and dirty. Pin
Pablo Aliskevicius19-Jul-11 2:39
memberPablo Aliskevicius19-Jul-11 2:39 
GeneralRe: There is no such thing as quick and dirty. Pin
ThatsAlok 20-Jul-11 1:07
member ThatsAlok 20-Jul-11 1:07 
GeneralShame on me: a race condition.... Pin
Pablo Aliskevicius28-May-08 8:39
memberPablo Aliskevicius28-May-08 8:39 
GeneralWhen multithreading is not an option... Pin
Pablo Aliskevicius19-Mar-07 10:18
memberPablo Aliskevicius19-Mar-07 10:18 
GeneralMore on thread procedures... Pin
Pablo Aliskevicius13-Oct-06 3:36
memberPablo Aliskevicius13-Oct-06 3:36 
General::PostThreadMessage. Pin
Pablo Aliskevicius11-Oct-06 8:05
memberPablo Aliskevicius11-Oct-06 8:05 
Multi threading is anything but boring.

A few days ago, I was asked to improve the performance of a program, which reads a FOX Pro table, generates SQL INSERT commands, and executes them against a database.

The way to do it was clear: read in one thread, write on another. To spice things up, since inserting is much slower than reading (all that index updates, you know), three writer threads were matched to the reader.
The writers' thread procedure looked like this (pseudo-code):


DWORD WINAPI ThreadProc(LPVOID pX)
{
    // Cast passed pointer to what it really is.
    // Initialize COM
    // Generate message pump
    ::PeekMessage(whatever);
    // Connect to database
    while (!done)
    {
        ::GetMessage(....)
        switch(msg.uMsg)
        {
            case WM_COMMAND: // Cast LPARAM to pointer to a Job, execute that job.
            break;
            case WM_QUIT:
            done = true;
            break;

        }
    }
    SetEvent(reallyDone);
    return 0;
}


Nice, right?
Tested it with 16K records: runs like the wind, results are fine.
64K records: still OK.
80K records: some start to get lost.

I've use ::PostThreadMessage() for quite some time: the caller allocates a Job, posts it to the queue, the worker thread pops it from the queue, executes it, and deletes it. All synchronization tasks are taken care of by the OS, which minimizes thread switches.

Well, you always have to read the fine print. And the fine print for ::PostThreadMessage() is that the queue size is 10,000 messages. That's a lot, if you have a few dozen long-running jobs (in the past, for me, that was the usual).

So, how could I handle it?

My first idea was the use of a 'thermostat'. An integer was interlock-incremented whenever a message was posted, and interlock-decremented whenever a job was executed, thus holding the count of messages in the queue.

The manager thread would test the queue size: if longer than 900 messages, it would Sleep for 50 milliseconds: if, after that, there were less than 1000 messages, it would try to post one (in a loop); if, after 5 tries the message was not posted yet, the job would be executed on the calling thread.

I didn't like it: whole lot of interlocking going on, and Sleep is by far not my favorite API.

Well, the bad news was as expected: performance went down by 30%, but still it was three times faster than the original program.
The good news: 80K records, and none got lost. 150K, and none got lost!

So I tried for 400K (the program should be able to send about a million): well, it got stuck after 215K. Playing with the thermostat settings helped a bit, but no cigar.

After a couple of hours, I gave up. Added std::queue to the mix, managed synchronization with a critical section (which protected this queue), and performance went back to good. Private bytes and CPU usage were totally flat, up to 400K records.

The program was ripe for the QA department.

What did I learn?

::PostThreadMessage() is a nice tool, but it has some limitations. Its usage: when you have just a few 'big' jobs, and in a program which runs, does its thing and exits. For long-running programs, or programs which send to the worker threads a lot of small jobs, you're better off rolling your own queue.

And yet, multithreading, when you know how to do it, can be a great way to make an impression, and to become the star of your company parties.



Pablo

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.


Advertise | Privacy | Mobile
Web03 | 2.8.150603.1 | Last Updated 4 Jul 2015
Copyright © CodeProject, 1999-2015
All Rights Reserved. Terms of Service
Layout: fixed | fluid