| line | stmt | bran | cond | sub | pod | time | code | 
| 1 |  |  |  |  |  |  | package IPC::LeaderBoard; | 
| 2 |  |  |  |  |  |  |  | 
| 3 | 1 |  |  | 1 |  | 27554 | use strict; | 
|  | 1 |  |  |  |  | 2 |  | 
|  | 1 |  |  |  |  | 24 |  | 
| 4 | 1 |  |  | 1 |  | 3 | use warnings; | 
|  | 1 |  |  |  |  | 1 |  | 
|  | 1 |  |  |  |  | 23 |  | 
| 5 |  |  |  |  |  |  |  | 
| 6 | 1 |  |  | 1 |  | 3 | use Fcntl ':flock';    # import LOCK_* constants | 
|  | 1 |  |  |  |  | 5 |  | 
|  | 1 |  |  |  |  | 99 |  | 
| 7 | 1 |  |  | 1 |  | 384 | use Guard; | 
|  | 1 |  |  |  |  | 434 |  | 
|  | 1 |  |  |  |  | 41 |  | 
| 8 | 1 |  |  | 1 |  | 490 | use IPC::ScoreBoard; | 
|  | 1 |  |  |  |  | 7216 |  | 
|  | 1 |  |  |  |  | 4 |  | 
| 9 | 1 |  |  | 1 |  | 597 | use Moo; | 
|  | 1 |  |  |  |  | 7963 |  | 
|  | 1 |  |  |  |  | 4 |  | 
| 10 | 1 |  |  | 1 |  | 1049 | use Path::Tiny; | 
|  | 1 |  |  |  |  | 2 |  | 
|  | 1 |  |  |  |  | 38 |  | 
| 11 | 1 |  |  | 1 |  | 374 | use namespace::clean; | 
|  | 1 |  |  |  |  | 6385 |  | 
|  | 1 |  |  |  |  | 3 |  | 
| 12 |  |  |  |  |  |  |  | 
| 13 |  |  |  |  |  |  | our $VERSION = '0.02'; | 
| 14 |  |  |  |  |  |  |  | 
| 15 |  |  |  |  |  |  | =head1 NAME | 
| 16 |  |  |  |  |  |  |  | 
| 17 |  |  |  |  |  |  | IPC::LeaderBoard - fast per-symbol online get/update information | 
| 18 |  |  |  |  |  |  |  | 
| 19 |  |  |  |  |  |  | =head1 VERSION | 
| 20 |  |  |  |  |  |  |  | 
| 21 |  |  |  |  |  |  | 0.02 | 
| 22 |  |  |  |  |  |  |  | 
| 23 |  |  |  |  |  |  | =head1 STATUS | 
| 24 |  |  |  |  |  |  |  | 
| 25 |  |  |  |  |  |  | =begin HTML | 
| 26 |  |  |  |  |  |  |  | 
| 27 |  |  |  |  |  |  |   | 
| 28 |  |  |  |  |  |  |   | 
| 29 |  |  |  |  |  |  |  | 
| 30 |  |  |  |  |  |  |  | 
| 31 |  |  |  |  |  |  | =end HTML | 
| 32 |  |  |  |  |  |  |  | 
| 33 |  |  |  |  |  |  |  | 
| 34 |  |  |  |  |  |  | =head1 SYNOPSIS | 
| 35 |  |  |  |  |  |  |  | 
| 36 |  |  |  |  |  |  | use IPC::LeaderBoard; | 
| 37 |  |  |  |  |  |  |  | 
| 38 |  |  |  |  |  |  | # in master-process | 
| 39 |  |  |  |  |  |  | my $master = IPC::LeaderBoard::create( | 
| 40 |  |  |  |  |  |  | n_slots           => 2,                          # number of symbols | 
| 41 |  |  |  |  |  |  | slot_shared_size  => 4,                          # number integers per slot, concurrent access | 
| 42 |  |  |  |  |  |  | slot_private_size => 2,                          # number integers per slot, non-concurrent access | 
| 43 |  |  |  |  |  |  | mmaped_file       => "/var/run/data/my.scores",  # mmaped file | 
| 44 |  |  |  |  |  |  | ); | 
| 45 |  |  |  |  |  |  | # ... initialize data here | 
| 46 |  |  |  |  |  |  |  | 
| 47 |  |  |  |  |  |  | # in slave processes | 
| 48 |  |  |  |  |  |  | my $slave  = IPC::LeaderBoard::attach( | 
| 49 |  |  |  |  |  |  | # exactly the same parameters as for master | 
| 50 |  |  |  |  |  |  | ); | 
| 51 |  |  |  |  |  |  |  | 
| 52 |  |  |  |  |  |  | my $leader_board = $slave; # or $master, does not matter | 
| 53 |  |  |  |  |  |  |  | 
| 54 |  |  |  |  |  |  | # get shared and private arrays of integers for the 0-th slot | 
| 55 |  |  |  |  |  |  | my ($shared, $private) = $leader_board->read_slot(0); | 
| 56 |  |  |  |  |  |  |  | 
| 57 |  |  |  |  |  |  | # update shared integers with values 1,2,3,4 and 0-th private integer | 
| 58 |  |  |  |  |  |  | # with value 6 | 
| 59 |  |  |  |  |  |  | my $success = $leader_board->update(0, [1, 2, 3, 4], 0 => 6, 1 => 8) | 
| 60 |  |  |  |  |  |  |  | 
| 61 |  |  |  |  |  |  | # $shared = [1, 2, 3, 4], $private = [6, 8] | 
| 62 |  |  |  |  |  |  | ($shared, $private) = $leader_board->read_slot(0); | 
| 63 |  |  |  |  |  |  |  | 
| 64 |  |  |  |  |  |  | # update just private integer with index 1 with value 2 | 
| 65 |  |  |  |  |  |  | $leader_board->update(0, 1 => 2); | 
| 66 |  |  |  |  |  |  |  | 
| 67 |  |  |  |  |  |  | # update just shared values of 0-th slot | 
| 68 |  |  |  |  |  |  | my $success = $leader_board->update(0, [1, 2, 3, 4]); | 
| 69 |  |  |  |  |  |  |  | 
| 70 |  |  |  |  |  |  | =head1 DESCRIPTION | 
| 71 |  |  |  |  |  |  |  | 
| 72 |  |  |  |  |  |  | LeaderBoard uses shared memory IPC to fast set/get integers on arbitrary row, | 
| 73 |  |  |  |  |  |  | (slot) defined by it's index. | 
| 74 |  |  |  |  |  |  |  | 
| 75 |  |  |  |  |  |  | There are the following assumptions: | 
| 76 |  |  |  |  |  |  |  | 
| 77 |  |  |  |  |  |  | =over 2 | 
| 78 |  |  |  |  |  |  |  | 
| 79 |  |  |  |  |  |  | =item * only one master is present | 
| 80 |  |  |  |  |  |  |  | 
| 81 |  |  |  |  |  |  | C method dies, if it founds that some other master ownes shared | 
| 82 |  |  |  |  |  |  | memory (file lock is used for that). | 
| 83 |  |  |  |  |  |  |  | 
| 84 |  |  |  |  |  |  | =item * master is launched before slaves | 
| 85 |  |  |  |  |  |  |  | 
| 86 |  |  |  |  |  |  | C dies, if slave finds, that master-owner isn't present, or, | 
| 87 |  |  |  |  |  |  | if it presents, the masters provider/symbol information isn't actual. | 
| 88 |  |  |  |  |  |  | In the last case master should be restarted first. | 
| 89 |  |  |  |  |  |  |  | 
| 90 |  |  |  |  |  |  | =item * there is no hot-deploy mechanism | 
| 91 |  |  |  |  |  |  |  | 
| 92 |  |  |  |  |  |  | Just restart master/slaves | 
| 93 |  |  |  |  |  |  |  | 
| 94 |  |  |  |  |  |  | =item * read slot before update it | 
| 95 |  |  |  |  |  |  |  | 
| 96 |  |  |  |  |  |  | The vesion/generation pattern is used do detect, whether update | 
| 97 |  |  |  |  |  |  | has been successfull or not. Update failure means, some other | 
| 98 |  |  |  |  |  |  | C instance updated the slot; you should re-read it | 
| 99 |  |  |  |  |  |  | and try uptate it again (if the update will be still actual after | 
| 100 |  |  |  |  |  |  | data refresh) | 
| 101 |  |  |  |  |  |  |  | 
| 102 |  |  |  |  |  |  | =item * no semantical difference between slave and master | 
| 103 |  |  |  |  |  |  |  | 
| 104 |  |  |  |  |  |  | Master was introduced to lock leadear board to prevent other masters | 
| 105 |  |  |  |  |  |  | connect to it and re-initialize (corrupt) data. After attach slave validates, | 
| 106 |  |  |  |  |  |  | that LeaderBoard is valid (i.e. number of slots, as well as the sizes | 
| 107 |  |  |  |  |  |  | of private and shared areas match to the declared). | 
| 108 |  |  |  |  |  |  |  | 
| 109 |  |  |  |  |  |  | Hence, master can be presented only by one instance, while slaves | 
| 110 |  |  |  |  |  |  | can be presented by multiple instances. | 
| 111 |  |  |  |  |  |  |  | 
| 112 |  |  |  |  |  |  | =item * slot data organization and consistency | 
| 113 |  |  |  |  |  |  |  | 
| 114 |  |  |  |  |  |  | A leaderboard is an array of slots of the same size: | 
| 115 |  |  |  |  |  |  |  | 
| 116 |  |  |  |  |  |  | +------------------------------------------------------------------------+ | 
| 117 |  |  |  |  |  |  | | slot 1                                                                 | | 
| 118 |  |  |  |  |  |  | +------------------------------------------------------------------------+ | 
| 119 |  |  |  |  |  |  | | slot 2                                                                 | | 
| 120 |  |  |  |  |  |  | +------------------------------------------------------------------------+ | 
| 121 |  |  |  |  |  |  | | ...                                                                    | | 
| 122 |  |  |  |  |  |  | +------------------------------------------------------------------------+ | 
| 123 |  |  |  |  |  |  | | slot N                                                                 | | 
| 124 |  |  |  |  |  |  | +------------------------------------------------------------------------+ | 
| 125 |  |  |  |  |  |  |  | 
| 126 |  |  |  |  |  |  | A slot is addressed by its index. | 
| 127 |  |  |  |  |  |  |  | 
| 128 |  |  |  |  |  |  | Each slot contains a spin-lock, a shared part, a generation field and a private part like | 
| 129 |  |  |  |  |  |  |  | 
| 130 |  |  |  |  |  |  | It is supposed, that only leader (independent for each slot) will update the shared part, | 
| 131 |  |  |  |  |  |  | while other competitors will update only own private parts, i.e.: | 
| 132 |  |  |  |  |  |  |  | 
| 133 |  |  |  |  |  |  | |      |        shared part       |        |                         private part                         | | 
| 134 |  |  |  |  |  |  | | spin |                          | gene-  | process1           | process2           | process3           | | 
| 135 |  |  |  |  |  |  | | lock | shr1 | shr2 | ... | shrN | ration | p1 | p2 | ... | pN | p1 | p2 | ... | pN | p1 | p2 | ... | pN | | 
| 136 |  |  |  |  |  |  |  | 
| 137 |  |  |  |  |  |  | All values (shrX and pX) in the leaderboard are integer numbers. Only the current leader updates | 
| 138 |  |  |  |  |  |  | the shared part, and does that in safe manner (i.e. protected by spin-lock and generation). Each process can | 
| 139 |  |  |  |  |  |  | update its own private part of a slot. | 
| 140 |  |  |  |  |  |  |  | 
| 141 |  |  |  |  |  |  | Read or write for integer values (shr1, p1, ..) read/write B is guaranteed | 
| 142 |  |  |  |  |  |  | by L, which in the final, uses special CPU-instructions for that. | 
| 143 |  |  |  |  |  |  |  | 
| 144 |  |  |  |  |  |  | The SpinLock pattern guarantees the safety of shared part update, i.e. in | 
| 145 |  |  |  |  |  |  | the case of two or more concurrent write request, they will be done in | 
| 146 |  |  |  |  |  |  | sequential manner. | 
| 147 |  |  |  |  |  |  |  | 
| 148 |  |  |  |  |  |  | The Generation pattern guarantees that you update the most recent values | 
| 149 |  |  |  |  |  |  | in the shared part of the slot, i.e. if some process updated shared | 
| 150 |  |  |  |  |  |  | part of the slot, between slot read and update operations of the | 
| 151 |  |  |  |  |  |  | current process, than, the update request of the current process | 
| 152 |  |  |  |  |  |  | would fail. You have re-read the slot, and try to update it again, but | 
| 153 |  |  |  |  |  |  | after re-read the update might be not required. | 
| 154 |  |  |  |  |  |  |  | 
| 155 |  |  |  |  |  |  | Both SpinLock and Generation patterns guarantee, that you'll never | 
| 156 |  |  |  |  |  |  | can made inconsistent C, or updating non-actual data. | 
| 157 |  |  |  |  |  |  |  | 
| 158 |  |  |  |  |  |  | In the same time, you might end up with the inconsistent C | 
| 159 |  |  |  |  |  |  | of the shared data: the individual values (integer) are consistent (atomic), | 
| 160 |  |  |  |  |  |  | but you they might belong to the different generations. There is an assumption | 
| 161 |  |  |  |  |  |  | in the C design, that it is B: would you try to update | 
| 162 |  |  |  |  |  |  | the shared data, the C will fail, hence, no any harm will occur. If | 
| 163 |  |  |  |  |  |  | you need to handle that, just check return value C. | 
| 164 |  |  |  |  |  |  |  | 
| 165 |  |  |  |  |  |  | There are no any guarantees for slot private data; but it isn't needed. | 
| 166 |  |  |  |  |  |  | The shared data should store information about leader, hence when a | 
| 167 |  |  |  |  |  |  | new leader arrives, it updates the information; or the current leader update | 
| 168 |  |  |  |  |  |  | it's information on the LeaderBoard in the appropriate slot. No data loss might | 
| 169 |  |  |  |  |  |  | occur. | 
| 170 |  |  |  |  |  |  |  | 
| 171 |  |  |  |  |  |  | When competitor (i.e. some process) updates private data, nobody else | 
| 172 |  |  |  |  |  |  | can update it (i.e. you shouldn't write progam such a way, that one | 
| 173 |  |  |  |  |  |  | process-competitor updates data of the other process-competitor), hence, | 
| 174 |  |  |  |  |  |  | private data cannot be corrupted if used properly. | 
| 175 |  |  |  |  |  |  |  | 
| 176 |  |  |  |  |  |  | The private data might be inconsistent on read (e.g. competitor1 reads | 
| 177 |  |  |  |  |  |  | private data of competitor2, while it is half-updated by competitor2); | 
| 178 |  |  |  |  |  |  | but that shoudl be B. If it is | 
| 179 |  |  |  |  |  |  | significant, use shared memory for that, re-design your approach (e.g | 
| 180 |  |  |  |  |  |  | use additional slots) or use some other module. | 
| 181 |  |  |  |  |  |  |  | 
| 182 |  |  |  |  |  |  | =back | 
| 183 |  |  |  |  |  |  |  | 
| 184 |  |  |  |  |  |  | The update process should be rather simple: C | 
| 185 |  |  |  |  |  |  | and then start all together. C / C should be wrappend into | 
| 186 |  |  |  |  |  |  | C (or C & friends), to repeat seveal attempts with some delay. | 
| 187 |  |  |  |  |  |  |  | 
| 188 |  |  |  |  |  |  | The C method might fail, (i.e. it does not returns true), when it detects, | 
| 189 |  |  |  |  |  |  | that somebody else already has changed an row. It is assumed that no any harm | 
| 190 |  |  |  |  |  |  | in it. If needed the row can be refreshed (re-read), and the next update | 
| 191 |  |  |  |  |  |  | might be successfull. | 
| 192 |  |  |  |  |  |  |  | 
| 193 |  |  |  |  |  |  | It is assumed, that if C returs outdated data and the C decision | 
| 194 |  |  |  |  |  |  | has been taken, than update will silently fail (return false), without any | 
| 195 |  |  |  |  |  |  | loud exceptions; so, the next read-update cycle might be successful, but | 
| 196 |  |  |  |  |  |  | probably, the updated values are already correct, so, no immediate update | 
| 197 |  |  |  |  |  |  | would occur. | 
| 198 |  |  |  |  |  |  |  | 
| 199 |  |  |  |  |  |  | =cut | 
| 200 |  |  |  |  |  |  |  | 
| 201 |  |  |  |  |  |  | has mmaped_file => ( | 
| 202 |  |  |  |  |  |  | is       => 'ro', | 
| 203 |  |  |  |  |  |  | required => 1 | 
| 204 |  |  |  |  |  |  | ); | 
| 205 |  |  |  |  |  |  |  | 
| 206 |  |  |  |  |  |  | has n_slots => ( | 
| 207 |  |  |  |  |  |  | is       => 'ro', | 
| 208 |  |  |  |  |  |  | required => 1 | 
| 209 |  |  |  |  |  |  | ); | 
| 210 |  |  |  |  |  |  |  | 
| 211 |  |  |  |  |  |  | has slot_shared_size => ( | 
| 212 |  |  |  |  |  |  | is       => 'ro', | 
| 213 |  |  |  |  |  |  | required => 1 | 
| 214 |  |  |  |  |  |  | ); | 
| 215 |  |  |  |  |  |  |  | 
| 216 |  |  |  |  |  |  | has slot_private_size => ( | 
| 217 |  |  |  |  |  |  | is       => 'ro', | 
| 218 |  |  |  |  |  |  | required => 1 | 
| 219 |  |  |  |  |  |  | ); | 
| 220 |  |  |  |  |  |  |  | 
| 221 |  |  |  |  |  |  | has _mode => ( | 
| 222 |  |  |  |  |  |  | is       => 'ro', | 
| 223 |  |  |  |  |  |  | required => 1 | 
| 224 |  |  |  |  |  |  | ); | 
| 225 |  |  |  |  |  |  |  | 
| 226 |  |  |  |  |  |  | has _score_board     => (is => 'rw'); | 
| 227 |  |  |  |  |  |  | has _fd              => (is => 'rw'); | 
| 228 |  |  |  |  |  |  | has _generation_idx  => (is => 'rw'); | 
| 229 |  |  |  |  |  |  | has _last_generation => (is => 'rw'); | 
| 230 |  |  |  |  |  |  | has _last_idx        => ( | 
| 231 |  |  |  |  |  |  | is      => 'rw', | 
| 232 |  |  |  |  |  |  | default => sub { -1 }); | 
| 233 |  |  |  |  |  |  |  | 
| 234 |  |  |  |  |  |  | sub BUILD { | 
| 235 | 9 |  |  | 9 | 0 | 90 | my $self = shift; | 
| 236 | 9 |  |  |  |  | 20 | my $mode = $self->_mode; | 
| 237 | 9 | 50 |  |  |  | 24 | die("unknown mode '$mode'") unless $mode =~ /(slave)|(master)/; | 
| 238 |  |  |  |  |  |  |  | 
| 239 |  |  |  |  |  |  | # construct ids (number, actually the order) for all symbols | 
| 240 |  |  |  |  |  |  | # and providers. Should be sorted to guaranttee the same | 
| 241 |  |  |  |  |  |  | # ids in different proccess | 
| 242 |  |  |  |  |  |  | # There is an assumption, that processes, using LeaderBoard, should | 
| 243 |  |  |  |  |  |  | # restarte in case of symbols/providers change. | 
| 244 |  |  |  |  |  |  |  | 
| 245 | 9 |  |  |  |  | 13 | my $filename = $self->mmaped_file; | 
| 246 | 9 | 50 | 66 |  |  | 143 | if (!(-e $filename) && ($mode eq 'slave')) { | 
| 247 | 0 |  |  |  |  | 0 | die("LeaderBoard ($filename) is abandoned, cannot attach to it (file not exists)"); | 
| 248 |  |  |  |  |  |  | } | 
| 249 |  |  |  |  |  |  |  | 
| 250 | 9 |  |  |  |  | 26 | my $scoreboard_path = path($filename); | 
| 251 | 9 | 100 |  |  |  | 246 | $scoreboard_path->touch if !-e $filename; | 
| 252 | 9 |  |  |  |  | 206 | my $fd = $scoreboard_path->filehandle('<'); | 
| 253 |  |  |  |  |  |  |  | 
| 254 | 9 |  |  |  |  | 465 | my $score_board; | 
| 255 | 9 | 100 |  |  |  | 19 | if ($mode eq 'slave') { | 
| 256 |  |  |  |  |  |  | # die, if slave was able to lock it, that means, that master | 
| 257 |  |  |  |  |  |  | # didn't accquired the exclusive lock, i.e. no master | 
| 258 | 5 | 100 |  |  |  | 11 | flock($fd, LOCK_SH | LOCK_NB) | 
| 259 |  |  |  |  |  |  | && die("LeaderBoard ($filename) is abandoned, cannot attach to it (shared lock obtained)"); | 
| 260 | 4 |  |  |  |  | 110 | my ($sb, $nslots, $slotsize, $extra) = IPC::ScoreBoard->open($filename); | 
| 261 |  |  |  |  |  |  | # just additional check, that providers/symbols information is actual | 
| 262 | 4 |  |  |  |  | 526 | my $declared_size = $self->slot_shared_size + $self->slot_private_size + 2; | 
| 263 | 4 | 50 |  |  |  | 10 | die("number of slots mismatch") unless $nslots == $self->n_slots; | 
| 264 | 4 | 50 |  |  |  | 13 | die("slot size mismatch") unless $slotsize == $declared_size; | 
| 265 | 4 |  |  |  |  | 5 | $score_board = $sb; | 
| 266 |  |  |  |  |  |  | } else { | 
| 267 |  |  |  |  |  |  | # die if we can't lock it, that means, another master-process | 
| 268 |  |  |  |  |  |  | # already acquired it | 
| 269 | 4 | 100 |  |  |  | 11 | flock($fd, LOCK_EX | LOCK_NB) | 
| 270 |  |  |  |  |  |  | || die("LeaderBoard ($filename) is owned by some other process, cannot lock it exclusively"); | 
| 271 |  |  |  |  |  |  | # we use the addtitional fields: for spinlock and generation | 
| 272 | 3 |  |  |  |  | 90 | my $declared_size = $self->slot_shared_size + $self->slot_private_size + 2; | 
| 273 | 3 |  |  |  |  | 20 | $score_board = IPC::ScoreBoard->named($filename, $self->n_slots, $declared_size, 0); | 
| 274 | 3 |  |  |  |  | 814 | $self->_fd($fd); | 
| 275 |  |  |  |  |  |  | } | 
| 276 | 7 |  |  |  |  | 21 | $self->_generation_idx($self->slot_shared_size + 1);    # [spin_lock | shared_data | generation | private_data ] | 
| 277 | 7 |  |  |  |  | 14 | $self->_score_board($score_board); | 
| 278 | 7 |  |  |  |  | 175 | return; | 
| 279 |  |  |  |  |  |  | } | 
| 280 |  |  |  |  |  |  |  | 
| 281 |  |  |  |  |  |  | sub DEMOLISH { | 
| 282 | 9 |  |  | 9 | 0 | 3235 | my $self = shift; | 
| 283 |  |  |  |  |  |  | # actually we need that only for tests | 
| 284 | 9 | 100 |  |  |  | 34 | if ($self->_mode eq 'master') { | 
| 285 | 4 | 100 |  |  |  | 21 | flock($self->_fd, LOCK_UN) if ($self->_fd); | 
| 286 |  |  |  |  |  |  | } | 
| 287 | 9 |  |  |  |  | 198 | return; | 
| 288 |  |  |  |  |  |  | } | 
| 289 |  |  |  |  |  |  |  | 
| 290 |  |  |  |  |  |  | sub attach { | 
| 291 | 5 |  |  | 5 | 0 | 515 | return IPC::LeaderBoard->new({ | 
| 292 |  |  |  |  |  |  | _mode => 'slave', | 
| 293 |  |  |  |  |  |  | @_, | 
| 294 |  |  |  |  |  |  | }); | 
| 295 |  |  |  |  |  |  | } | 
| 296 |  |  |  |  |  |  |  | 
| 297 |  |  |  |  |  |  | sub create { | 
| 298 | 4 |  |  | 4 | 0 | 15984 | return IPC::LeaderBoard->new({ | 
| 299 |  |  |  |  |  |  | _mode => 'master', | 
| 300 |  |  |  |  |  |  | @_, | 
| 301 |  |  |  |  |  |  | }); | 
| 302 |  |  |  |  |  |  | } | 
| 303 |  |  |  |  |  |  |  | 
| 304 |  |  |  |  |  |  | # our use-case implies, that if we read a bit outdated data, this is OK, because | 
| 305 |  |  |  |  |  |  | # the generation field will be outdated, hence, no update would occur | 
| 306 |  |  |  |  |  |  | sub read_slot { | 
| 307 | 9 |  |  | 9 | 0 | 24 | my ($self, $idx) = @_; | 
| 308 | 9 | 50 | 33 |  |  | 53 | die("wrong index") if ($idx >= $self->n_slots) || $idx < 0; | 
| 309 |  |  |  |  |  |  |  | 
| 310 | 9 |  |  |  |  | 41 | my @all_values = $self->_score_board->get_all($idx); | 
| 311 |  |  |  |  |  |  | # drop spinlock and generation | 
| 312 | 9 |  |  |  |  | 20 | my $generation = splice @all_values, $self->_generation_idx, 1; | 
| 313 | 9 |  |  |  |  | 26 | splice @all_values, 0, 1; | 
| 314 |  |  |  |  |  |  |  | 
| 315 |  |  |  |  |  |  | # record generation + index for further possible update | 
| 316 | 9 |  |  |  |  | 14 | $self->_last_idx($idx); | 
| 317 | 9 |  |  |  |  | 11 | $self->_last_generation($generation); | 
| 318 |  |  |  |  |  |  |  | 
| 319 |  |  |  |  |  |  | # separate shared and private data | 
| 320 | 9 |  |  |  |  | 11 | my $shared_size    = $self->slot_shared_size; | 
| 321 | 9 |  |  |  |  | 24 | my @shared_values  = @all_values[0 .. $shared_size - 1]; | 
| 322 | 9 |  |  |  |  | 19 | my @private_values = @all_values[$shared_size .. $shared_size + $self->slot_private_size - 1]; | 
| 323 |  |  |  |  |  |  |  | 
| 324 | 9 |  |  |  |  | 52 | return \@shared_values, \@private_values; | 
| 325 |  |  |  |  |  |  | } | 
| 326 |  |  |  |  |  |  |  | 
| 327 |  |  |  |  |  |  | sub update { | 
| 328 | 5 |  |  | 5 | 1 | 7 | my ($self, $idx, @rest) = @_; | 
| 329 | 5 | 100 | 66 |  |  | 28 | my $values           = (@rest && ref($rest[0]) eq 'ARRAY') ? shift(@rest) : undef; | 
| 330 | 5 |  |  |  |  | 13 | my %private_values   = @rest; | 
| 331 | 5 |  |  |  |  | 5 | my $operation_result = 0; | 
| 332 | 5 | 50 | 33 |  |  | 29 | die("wrong index") if ($idx >= $self->n_slots) || $idx < 0; | 
| 333 | 5 | 50 |  |  |  | 18 | die("update for only last read index is allowed") if $idx != $self->_last_idx; | 
| 334 |  |  |  |  |  |  |  | 
| 335 | 5 |  |  |  |  | 8 | my $sb = $self->_score_board; | 
| 336 |  |  |  |  |  |  |  | 
| 337 |  |  |  |  |  |  | # updating shared values | 
| 338 | 5 | 100 |  |  |  | 9 | if ($values) { | 
| 339 | 4 | 50 |  |  |  | 11 | die("values size mismatch slot size") if @$values != $self->slot_shared_size; | 
| 340 |  |  |  |  |  |  | # obtain spin-lock | 
| 341 | 4 |  |  |  |  | 21 | $sb->decr($idx, 0) until $sb->incr($idx, 0) == 1; | 
| 342 |  |  |  |  |  |  | # release the lock at the end of the scope | 
| 343 | 4 |  |  | 4 |  | 18 | scope_guard { $sb->decr($idx, 0) }; | 
|  | 4 |  |  |  |  | 13 |  | 
| 344 |  |  |  |  |  |  |  | 
| 345 |  |  |  |  |  |  | # now we hold the record, nobody else can update it. | 
| 346 |  |  |  |  |  |  | # Atomically read generation value via increment it to zero. | 
| 347 |  |  |  |  |  |  | # The simple $sb->get(...) cannot be used, because it does not guarantees | 
| 348 |  |  |  |  |  |  | # atomicity, i.e. slot re-write is possible due to L1/L2 caches in CPU | 
| 349 | 4 |  |  |  |  | 9 | my $actual_generation = $sb->incr($idx, $self->_generation_idx, 0); | 
| 350 | 4 | 100 |  |  |  | 12 | if ($actual_generation == $self->_last_generation) { | 
| 351 |  |  |  |  |  |  | # now we are sure, that nobody else updated the record since our last read | 
| 352 |  |  |  |  |  |  | # so we can safely update it | 
| 353 |  |  |  |  |  |  |  | 
| 354 |  |  |  |  |  |  | # +1 because the 1st field is spinlock | 
| 355 | 2 |  |  |  |  | 17 | $sb->set($idx, $_ + 1, $values->[$_]) for (0 .. @$values - 1); | 
| 356 |  |  |  |  |  |  | # increment the generation field | 
| 357 | 2 |  |  |  |  | 6 | $sb->incr($idx, $self->_generation_idx); | 
| 358 |  |  |  |  |  |  | # success | 
| 359 | 2 |  |  |  |  | 6 | $operation_result = 1; | 
| 360 |  |  |  |  |  |  | } | 
| 361 |  |  |  |  |  |  | } | 
| 362 |  |  |  |  |  |  |  | 
| 363 |  |  |  |  |  |  | # updating private values | 
| 364 | 5 | 100 |  |  |  | 14 | if (%private_values) { | 
| 365 | 4 |  |  |  |  | 8 | my $idx_delta = $self->_generation_idx + 1; | 
| 366 | 4 |  |  |  |  | 13 | while (my ($private_idx, $value) = each %private_values) { | 
| 367 | 5 | 50 |  |  |  | 16 | die("wrong private index") if $private_idx >= $self->slot_private_size; | 
| 368 | 5 |  |  |  |  | 21 | $sb->set($idx, $private_idx + $idx_delta, $value); | 
| 369 |  |  |  |  |  |  | } | 
| 370 |  |  |  |  |  |  | } | 
| 371 |  |  |  |  |  |  |  | 
| 372 | 5 |  |  |  |  | 21 | return $operation_result; | 
| 373 |  |  |  |  |  |  | } | 
| 374 |  |  |  |  |  |  |  | 
| 375 |  |  |  |  |  |  |  | 
| 376 |  |  |  |  |  |  |  | 
| 377 |  |  |  |  |  |  | =head1 AUTHOR | 
| 378 |  |  |  |  |  |  |  | 
| 379 |  |  |  |  |  |  | binary.com, C<<  >> | 
| 380 |  |  |  |  |  |  |  | 
| 381 |  |  |  |  |  |  | =head1 BUGS | 
| 382 |  |  |  |  |  |  |  | 
| 383 |  |  |  |  |  |  | Please report any bugs or feature requests to | 
| 384 |  |  |  |  |  |  | L. | 
| 385 |  |  |  |  |  |  |  | 
| 386 |  |  |  |  |  |  | =head1 LICENSE AND COPYRIGHT | 
| 387 |  |  |  |  |  |  |  | 
| 388 |  |  |  |  |  |  | Copyright (C) 2016 binary.com | 
| 389 |  |  |  |  |  |  |  | 
| 390 |  |  |  |  |  |  | This program is free software; you can redistribute it and/or modify it | 
| 391 |  |  |  |  |  |  | under the terms of the the Artistic License (2.0). You may obtain a | 
| 392 |  |  |  |  |  |  | copy of the full license at: | 
| 393 |  |  |  |  |  |  |  | 
| 394 |  |  |  |  |  |  | L | 
| 395 |  |  |  |  |  |  |  | 
| 396 |  |  |  |  |  |  | Any use, modification, and distribution of the Standard or Modified | 
| 397 |  |  |  |  |  |  | Versions is governed by this Artistic License. By using, modifying or | 
| 398 |  |  |  |  |  |  | distributing the Package, you accept this license. Do not use, modify, | 
| 399 |  |  |  |  |  |  | or distribute the Package, if you do not accept this license. | 
| 400 |  |  |  |  |  |  |  | 
| 401 |  |  |  |  |  |  | If your Modified Version has been derived from a Modified Version made | 
| 402 |  |  |  |  |  |  | by someone other than you, you are nevertheless required to ensure that | 
| 403 |  |  |  |  |  |  | your Modified Version complies with the requirements of this license. | 
| 404 |  |  |  |  |  |  |  | 
| 405 |  |  |  |  |  |  | This license does not grant you the right to use any trademark, service | 
| 406 |  |  |  |  |  |  | mark, tradename, or logo of the Copyright Holder. | 
| 407 |  |  |  |  |  |  |  | 
| 408 |  |  |  |  |  |  | This license includes the non-exclusive, worldwide, free-of-charge | 
| 409 |  |  |  |  |  |  | patent license to make, have made, use, offer to sell, sell, import and | 
| 410 |  |  |  |  |  |  | otherwise transfer the Package with respect to any patent claims | 
| 411 |  |  |  |  |  |  | licensable by the Copyright Holder that are necessarily infringed by the | 
| 412 |  |  |  |  |  |  | Package. If you institute patent litigation (including a cross-claim or | 
| 413 |  |  |  |  |  |  | counterclaim) against any party alleging that the Package constitutes | 
| 414 |  |  |  |  |  |  | direct or contributory patent infringement, then this Artistic License | 
| 415 |  |  |  |  |  |  | to you shall terminate on the date that such litigation is filed. | 
| 416 |  |  |  |  |  |  |  | 
| 417 |  |  |  |  |  |  | Disclaimer of Warranty: THE PACKAGE IS PROVIDED BY THE COPYRIGHT HOLDER | 
| 418 |  |  |  |  |  |  | AND CONTRIBUTORS "AS IS' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES. | 
| 419 |  |  |  |  |  |  | THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR | 
| 420 |  |  |  |  |  |  | PURPOSE, OR NON-INFRINGEMENT ARE DISCLAIMED TO THE EXTENT PERMITTED BY | 
| 421 |  |  |  |  |  |  | YOUR LOCAL LAW. UNLESS REQUIRED BY LAW, NO COPYRIGHT HOLDER OR | 
| 422 |  |  |  |  |  |  | CONTRIBUTOR WILL BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, OR | 
| 423 |  |  |  |  |  |  | CONSEQUENTIAL DAMAGES ARISING IN ANY WAY OUT OF THE USE OF THE PACKAGE, | 
| 424 |  |  |  |  |  |  | EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. | 
| 425 |  |  |  |  |  |  |  | 
| 426 |  |  |  |  |  |  | =cut | 
| 427 |  |  |  |  |  |  |  | 
| 428 |  |  |  |  |  |  | 1; |